From abegen@cisco.com Thu Feb 10 12:51:45 2011 Return-Path: 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 58A623A6901 for ; Thu, 10 Feb 2011 12:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 IqrxSk7YjiuI for ; Thu, 10 Feb 2011 12:51:44 -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 035533A6833 for ; Thu, 10 Feb 2011 12:51:44 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAbfU02rRN+K/2dsb2JhbAClanOfMZszgn0TgkwEhQGKMA X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="661640329" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2011 20:51:54 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1AKpstN013969; Thu, 10 Feb 2011 20:51:54 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.4675); Thu, 10 Feb 2011 12:51:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Feb 2011 12:51:02 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7BA9@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ops/Management Cons. text for fecframe Thread-Index: AcvJX4LOUPpFWWZQSDGUx+2+eq2IFg== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 10 Feb 2011 20:51:54.0029 (UTC) FILETIME=[592DFDD0:01CBC964] Cc: Sean Turner , Russ Housley , dromasca@avaya.com Subject: [Fecframe] Ops/Management Cons. text for fecframe 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: , X-List-Received-Date: Thu, 10 Feb 2011 20:51:45 -0000 We have not seen any email from the DISCUSS holders (except David) = regarding the framework draft in the mailing list (I did not see any = private email, either and for some reason the system is not including me = in the emails from IESG). We need to publish this specification as it is = holding several other documents, and even the WG itself (Clearly, many = of us are eager to close the WG). Here is a summary of where we stand now: The DISCUSS from Russ H. is about some inconsistency in section 5, which = was fixed 2 versions ago. The DISCUSS Sean T. is about the security related issues, which were = addressed in the last revision. Russ, Sean, if you still have issues with the revised text, please raise = them. The DISCUSS from Dan R. and David H. are related to ops/management = issues. We had a lot discussion on this in the mailing list, and the = text below attempts to reflect the view of the WG on this subject. We would like to get your (WG individuals but in particular the DISCUSS = holders) comments on this text. The sooner the better as we would like = to close this issue before the next meeting and ship the draft to the = editor. Approvals/objections are welcome as usual. -acbegen 10. Operations and Management Considerations The question of operating and managing the FEC Framework and the associated FEC scheme(s) is of high practical importance. The goals of this section are to discuss the general requirements, aspects related to a specific deployment and solutions whenever possible. In particular, this section discusses the questions of interoperability across vendors/use cases and whether defining mandatory to implement (but not mandatory to use) solutions is beneficial. 10.1. What are the Key Aspects to Consider? Several aspects need to be considered since they will directly impact the way the FEC Framework and the associated FEC schemes can be operated and managed. This section lists them as follows: o A Single Small Generic Component within a Larger (and Often Legacy) Solution: The FEC Framework is one component within a larger solution which includes both one or several upper-layer applications (that generate one or several ADU flows) and an underlying protocol stack. A key design principle is that the FEC Framework should be able to work without making any assumption with respect to either the upper-layer application(s) or the underlying protocol stack, even if there are special cases where assumptions are made. o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to- Many without Feedback Scenarios: The FEC Framework can be used in use cases that completely differ from one another. Some use cases are one-way (e.g., in broadcast networks), with either a one-to- one, one-to-many or many-to-many transmission model, and the receiver(s) cannot send any feedback to the sender(s). Other use cases follow a bidirectional one-to-one, one-to-many, or many-to- many scenario, and the receiver(s) can send feedback to the sender(s). o Non-FEC Framework Capable Receivers: With the one-to-many and many-to-many use cases, the receiver population might have different capabilities with respect to the FEC Framework itself and the supported FEC schemes. Some receivers might not be capable of decoding the repair packets belonging to a particular FEC scheme, while some other receivers might not be supporting the FEC Framework at all. o Internet vs. non-Internet Networks: The FEC Framework can be useful in many use cases that use a transport network that is not the public Internet (e.g., with IPTV or Mobile TV). In such networks, the operational and management considerations can be achieved through an open or proprietary solution, which is specified outside of the IETF. o Congestion Control Considerations: See Section 8 for a discussion on whether congestion control is needed or not, and its relationships with the FEC Framework. o Within End-Systems vs. within Middleboxes: The FEC Framework can be used within end-systems, very close to the upper-layer application, or within dedicated middleboxes, for instance when it is desired to protect one or several flows while they cross a lossy channel between two or more remote sites. o Protecting a Single Flow vs. Several Flows Globally: The FEC Framework can be used to protect a single flow, or several flows globally. 10.2. Operational and Management Recommendations Overall, from the discussion of Section 10.1, it is clear that the CDPs and FEC schemes compatible with the FEC Framework widely differ in their capabilities, application and deployment scenarios such that a common operation and management tool that works well for all of them does not exist. Thus, as a design choice, the FEC Framework does not dictate the use of any particular technology or protocol for transporting FEC data, managing the hosts, signaling the configuration information or encoding the configuration information. This provides flexibility and was one of the main goals of the FEC Framework. However, this section gives some recommendations. o A Single Small Generic Component within a Larger (and Often Legacy) Solution: It is anticipated that the FEC Framework will often be used to protect one or several RTP streams. Therefore, there are use cases that may take advantage of RTCP to collect feedback information, and one can take advantage of the associated tools to operate and manage the FEC Framework instance along with the associated FEC schemes. o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to- Many without Feedback Scenarios: With use cases that are one-way, the FEC Framework sender does not have any way to gather feedback from receivers. With use cases that are bidirectional, the FEC Framework sender can collect detailed feedback (e.g., in case of a one-to-one scenario) or at least occasional feedback (e.g., in case of a multicast, one-to-many scenario). All these applications have naturally different operational and management aspects. If any, they also have different requirements or features for collecting feedback, processing it and acting on it. The data structures for carrying the feedback also vary. o Non-FEC Framework Capable Receivers: Section 5.3 gives recommendations on how to provide backward compatibility in presence of receivers that cannot support the FEC scheme being used, or the FEC Framework itself: basically the use of Explicit Source FEC Payload ID is banned. Additionally, a non-FEC Framework capable receiver MUST also have a means not to receive the repair packets that it will not be able to decode in the first place or a means to identify and discard them appropriately upon receiving them. This can be achieved by sending repair packets on a different transport-layer flow. In case of an RTP source flow, this can also be achieved by using an RTP framing for FEC repair packets with a different payload type. Both source and repair packets can then be sent on the same transport-layer flow. It is the responsibility of the sender to select the appropriate mechanism when needed. o Congestion Control Considerations: See Section 8 for a discussion on whether congestion control is needed or not, and its relationships with the FEC Framework. o Within End-Systems vs. within Middleboxes: When the FEC Framework is used within middleboxes, it is RECOMMENDED that the paths between the hosts where the sending applications run and the middlebox that performs FEC encoding be as reliable as possible, since these paths are not protected against erasures by default. Similarly, it is RECOMMENDED that the paths between the middleboxes that perform FEC decoding and the end-systems where the receiving applications operate, in situations where this is a different host, be as reliable as possible since these paths are not protected against losses by default. The recommendation for the sending side is particularly important with FEC schemes that do not modify the ADU for backward compatibility purposes (i.e. do not use any Explicit Source FEC Payload ID) and rely for instance on the RTP sequence number field to identify FEC source packets within their source block. In this case, a loss on this path directly leads to a gap in the RTP sequence number space seen by the FECFRAME instance. This MUST be considered during source block creation by the FEC scheme. With FEC schemes that indicate in the Repair FEC Payload ID, for each source block, the base RTP sequence number and number of consecutive RTP packets that belong to this source block, an ADU loss requires to switch to a new source block. This SHOULD be discussed in the FEC scheme when there is a chance of losing a packet. o Protecting a Single Flow vs. Several Flows Globally: In the general case, the various ADU flows that are globally protected can have different features, and in particular different real-time requirements (in case of real-time flows). The process of globally protecting these flows SHOULD take into account the requirements of each individual flow. In particular, it would be counter-productive to add repair traffic to a real-time flow for which the FEC decoding delay at a receiver makes decoded ADUs for this flow useless because they do not satisfy the associated real- time constraints. From a practical point of view, this means that the source block creation process at the sending FEC Framework instance, SHOULD consider the most stringent real-time requirements of the ADU flows being globally protected. From luby@qualcomm.com Thu Feb 10 15:57:15 2011 Return-Path: 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 9269D3A69ED for ; Thu, 10 Feb 2011 15:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 pgImzbb0Ry2y for ; Thu, 10 Feb 2011 15:57:13 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C7E363A6AEC for ; Thu, 10 Feb 2011 15:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1297382247; x=1328918247; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"A li=20C.=20Begen=20(abegen)"=20,=20"fecf rame@ietf.org"=0D=0A=09|CC:=20Sean=20T urner=20,=20Russ=20Housley=20,=0D=0A=09"dromasca@avaya.com"=20,=20"Luby,=20Michael"=0D=0A=09 |Date:=20Thu,=2010=20Feb=202011=2015:57:16=20-0800 |Subject:=20Re:=20[Fecframe]=20Ops/Management=20Cons.=20t ext=20for=20fecframe|Thread-Topic:=20[Fecframe]=20Ops/Man agement=20Cons.=20text=20for=20fecframe|Thread-Index:=20A cvJX4LOUPpFWWZQSDGUx+2+eq2IFgAHruXh|Message-ID:=20|In-Reply-To:=20<04CAD96D4C5A3D 48B1919248A8FE0D540E4C7BA9@xmb-sjc-215.amer.cisco.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.8.0.101117|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ePOgVJbYn8fihy/qbegZ39XgyCMGLwrYS6rfzp0hOLI=; b=nkc6q/mY6iioOF/M5ETp16ZdyFUsuNLKe6PaibPdRGN4GHYAIp8sL0uG 90DAnElmYBcDnzap8zNXks8MWVG4VU235vskfQIhJGLNY3qUlie0Gz8zo YmLAvWk3LHYZPIpiousDgqGw5DaD5A3H3qJYD7CVGpKaDsXqsaF00mBRM s=; X-IronPort-AV: E=McAfee;i="5400,1158,6253"; a="73772218" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 10 Feb 2011 15:57:26 -0800 X-IronPort-AV: E=Sophos;i="4.60,451,1291622400"; d="scan'208";a="29278970" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 10 Feb 2011 15:57:23 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 10 Feb 2011 15:57:23 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Thu, 10 Feb 2011 15:57:14 -0800 From: "Luby, Michael" To: "Ali C. Begen (abegen)" , "fecframe@ietf.org" Date: Thu, 10 Feb 2011 15:57:16 -0800 Thread-Topic: [Fecframe] Ops/Management Cons. text for fecframe Thread-Index: AcvJX4LOUPpFWWZQSDGUx+2+eq2IFgAHruXh Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7BA9@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dromasca@avaya.com" , Sean Turner , Russ Housley Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe 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: , X-List-Received-Date: Thu, 10 Feb 2011 23:57:15 -0000 This looks good Ali. One thing to perhaps add at the end of Section 10.2 i= s that if multiple "source flows" are protected by a single FEC repair stream (generated from the bundle of the source flows) then it should be the case that all of these flows are received by receivers who expect to receive and use the FEC repair stream generated from them (as otherwise the source flow= s that are not received will be considered as loss by the receiver, and also it might allow the receiver to recover flows that are not meant for it to receive, a security concern). I guess perhaps it is good to add a general security statement that says that it is important to only allow FEC repair be received by receivers for which all of the original source from which the FEC repair is generated can be received by those receivers. (Otherwise, the receivers might be able to recover source flows using FEC repair that they are not supposed to receive.)=20 On 2/10/11 12:51 PM, "Ali C. Begen (abegen)" wrote: > We have not seen any email from the DISCUSS holders (except David) regard= ing > the framework draft in the mailing list (I did not see any private email, > either and for some reason the system is not including me in the emails f= rom > IESG). We need to publish this specification as it is holding several oth= er > documents, and even the WG itself (Clearly, many of us are eager to close= the > WG). >=20 > Here is a summary of where we stand now: >=20 > The DISCUSS from Russ H. is about some inconsistency in section 5, which = was > fixed 2 versions ago. >=20 > The DISCUSS Sean T. is about the security related issues, which were addr= essed > in the last revision. >=20 > Russ, Sean, if you still have issues with the revised text, please raise = them. >=20 > The DISCUSS from Dan R. and David H. are related to ops/management issues= . We > had a lot discussion on this in the mailing list, and the text below atte= mpts > to reflect the view of the WG on this subject. >=20 > We would like to get your (WG individuals but in particular the DISCUSS > holders) comments on this text. The sooner the better as we would like to > close this issue before the next meeting and ship the draft to the editor= . >=20 > Approvals/objections are welcome as usual. >=20 > -acbegen >=20 >=20 > 10. Operations and Management Considerations >=20 > The question of operating and managing the FEC Framework and the > associated FEC scheme(s) is of high practical importance. The goals > of this section are to discuss the general requirements, aspects > related to a specific deployment and solutions whenever possible. >=20 > In particular, this section discusses the questions of > interoperability across vendors/use cases and whether defining > mandatory to implement (but not mandatory to use) solutions is > beneficial. >=20 > 10.1. What are the Key Aspects to Consider? >=20 > Several aspects need to be considered since they will directly impact > the way the FEC Framework and the associated FEC schemes can be > operated and managed. >=20 > This section lists them as follows: >=20 > o A Single Small Generic Component within a Larger (and Often > Legacy) Solution: The FEC Framework is one component within a > larger solution which includes both one or several upper-layer > applications (that generate one or several ADU flows) and an > underlying protocol stack. A key design principle is that the FEC > Framework should be able to work without making any assumption > with respect to either the upper-layer application(s) or the > underlying protocol stack, even if there are special cases where > assumptions are made. >=20 > o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to- > Many without Feedback Scenarios: The FEC Framework can be used in > use cases that completely differ from one another. Some use cases > are one-way (e.g., in broadcast networks), with either a one-to- > one, one-to-many or many-to-many transmission model, and the > receiver(s) cannot send any feedback to the sender(s). Other use > cases follow a bidirectional one-to-one, one-to-many, or many-to- > many scenario, and the receiver(s) can send feedback to the > sender(s). >=20 > o Non-FEC Framework Capable Receivers: With the one-to-many and > many-to-many use cases, the receiver population might have > different capabilities with respect to the FEC Framework itself > and the supported FEC schemes. Some receivers might not be > capable of decoding the repair packets belonging to a particular > FEC scheme, while some other receivers might not be supporting the > FEC Framework at all. >=20 > o Internet vs. non-Internet Networks: The FEC Framework can be > useful in many use cases that use a transport network that is not > the public Internet (e.g., with IPTV or Mobile TV). In such > networks, the operational and management considerations can be > achieved through an open or proprietary solution, which is > specified outside of the IETF. >=20 > o Congestion Control Considerations: See Section 8 for a discussion > on whether congestion control is needed or not, and its > relationships with the FEC Framework. >=20 > o Within End-Systems vs. within Middleboxes: The FEC Framework can > be used within end-systems, very close to the upper-layer > application, or within dedicated middleboxes, for instance when it > is desired to protect one or several flows while they cross a > lossy channel between two or more remote sites. >=20 > o Protecting a Single Flow vs. Several Flows Globally: The FEC > Framework can be used to protect a single flow, or several flows > globally. >=20 > 10.2. Operational and Management Recommendations >=20 > Overall, from the discussion of Section 10.1, it is clear that the > CDPs and FEC schemes compatible with the FEC Framework widely differ > in their capabilities, application and deployment scenarios such that > a common operation and management tool that works well for all of > them does not exist. Thus, as a design choice, the FEC Framework > does not dictate the use of any particular technology or protocol for > transporting FEC data, managing the hosts, signaling the > configuration information or encoding the configuration information. > This provides flexibility and was one of the main goals of the FEC > Framework. However, this section gives some recommendations. >=20 > o A Single Small Generic Component within a Larger (and Often > Legacy) Solution: It is anticipated that the FEC Framework will > often be used to protect one or several RTP streams. Therefore, > there are use cases that may take advantage of RTCP to collect > feedback information, and one can take advantage of the associated > tools to operate and manage the FEC Framework instance along with > the associated FEC schemes. >=20 > o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to- > Many without Feedback Scenarios: With use cases that are one-way, > the FEC Framework sender does not have any way to gather feedback > from receivers. With use cases that are bidirectional, the FEC > Framework sender can collect detailed feedback (e.g., in case of a > one-to-one scenario) or at least occasional feedback (e.g., in > case of a multicast, one-to-many scenario). All these > applications have naturally different operational and management > aspects. If any, they also have different requirements or > features for collecting feedback, processing it and acting on it. > The data structures for carrying the feedback also vary. >=20 > o Non-FEC Framework Capable Receivers: Section 5.3 gives > recommendations on how to provide backward compatibility in > presence of receivers that cannot support the FEC scheme being > used, or the FEC Framework itself: basically the use of Explicit > Source FEC Payload ID is banned. Additionally, a non-FEC > Framework capable receiver MUST also have a means not to receive > the repair packets that it will not be able to decode in the first > place or a means to identify and discard them appropriately upon > receiving them. This can be achieved by sending repair packets on > a different transport-layer flow. In case of an RTP source flow, > this can also be achieved by using an RTP framing for FEC repair > packets with a different payload type. Both source and repair > packets can then be sent on the same transport-layer flow. It is > the responsibility of the sender to select the appropriate > mechanism when needed. >=20 > o Congestion Control Considerations: See Section 8 for a discussion > on whether congestion control is needed or not, and its > relationships with the FEC Framework. >=20 > o Within End-Systems vs. within Middleboxes: When the FEC Framework > is used within middleboxes, it is RECOMMENDED that the paths > between the hosts where the sending applications run and the > middlebox that performs FEC encoding be as reliable as possible, > since these paths are not protected against erasures by default. > Similarly, it is RECOMMENDED that the paths between the > middleboxes that perform FEC decoding and the end-systems where > the receiving applications operate, in situations where this is a > different host, be as reliable as possible since these paths are > not protected against losses by default. >=20 > The recommendation for the sending side is particularly important > with FEC schemes that do not modify the ADU for backward > compatibility purposes (i.e. do not use any Explicit Source FEC > Payload ID) and rely for instance on the RTP sequence number field > to identify FEC source packets within their source block. In this > case, a loss on this path directly leads to a gap in the RTP > sequence number space seen by the FECFRAME instance. This MUST be > considered during source block creation by the FEC scheme. With > FEC schemes that indicate in the Repair FEC Payload ID, for each > source block, the base RTP sequence number and number of > consecutive RTP packets that belong to this source block, an ADU > loss requires to switch to a new source block. This SHOULD be > discussed in the FEC scheme when there is a chance of losing a > packet. >=20 > o Protecting a Single Flow vs. Several Flows Globally: In the > general case, the various ADU flows that are globally protected > can have different features, and in particular different real-time > requirements (in case of real-time flows). The process of > globally protecting these flows SHOULD take into account the > requirements of each individual flow. In particular, it would be > counter-productive to add repair traffic to a real-time flow for > which the FEC decoding delay at a receiver makes decoded ADUs for > this flow useless because they do not satisfy the associated real- > time constraints. From a practical point of view, this means that > the source block creation process at the sending FEC Framework > instance, SHOULD consider the most stringent real-time > requirements of the ADU flows being globally protected. >=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From vincent.roca@inrialpes.fr Fri Feb 11 01:02:30 2011 Return-Path: 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 E7ACD3A69DD for ; Fri, 11 Feb 2011 01:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 kEdRekqDAyph for ; Fri, 11 Feb 2011 01:02:30 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id C5E303A6921 for ; Fri, 11 Feb 2011 01:02:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,454,1291590000"; d="scan'208";a="91107826" Received: from ral022r.vpn.inria.fr ([128.93.178.22]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 11 Feb 2011 10:02:42 +0100 Message-ID: <4D54FB32.9070601@inrialpes.fr> Date: Fri, 11 Feb 2011 10:02:42 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "fecframe@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Fecframe] About the Generic Explicit Source FEC Payload ID 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: , X-List-Received-Date: Fri, 11 Feb 2011 09:02:31 -0000 Hi everybody, While preparing the new O&M section proposal with Ali, we spotted two points we'd like to discuss. Here is the first one. Point 1: about the "Generic Explicit Source FEC Payload ID" ------------------------------------------------- Section 5.3.1. of the FECFRAME Framework I-D says: "In order to apply FEC protection using multiple FEC schemes to a single source flow, all schemes have to use the same Explicit Source FEC Payload ID format. In order to enable this, it is RECOMMENDED that FEC schemes support the Generic Explicit Source FEC Payload ID format described below." Then it explains what is meant by "Generic source FEC payload ID", i.e. a two byte field, in network byte order, that contains a sequence number shared by all FEC schemes. When reading 5.3.1, it is clear to me that this field is to be carried in an **Explicit Source FEC Payload ID**, i.e. at the end of the packet. Section 5.3.1 does not suggest to reuse any sequence number that may exist in the application flow (like the RTP sequence number) to achieve this goal. We also notice that the sentence is rather strong in what FEC Schemes should define (it says "RECOMMENDED"). It turns out that none of the current FEC Schemes define such a Generic Explicit FEC Payload ID. Additionally, the only use-case where an application flow is protected by two different AL-FEC codes and that is considered by IETF is the DVB-IPTV (draft-ietf-fecframe-dvb-al-fec-04). In that case the solution consists in reusing the RTP SN field, rather than defining a "Generic source FEC payload ID". So we see two options here: 1- Extend section 5.3.1 recommendations so that, if the application flow already includes a sequence number that fulfills the requirements of section 5.3.1, then this field can be used to fulfill the needs specified here. But this is not strictly speaking a special case of Explicit FEC Payload ID (nothing is added to source packets). 2- or weaken current 5.3.1 recommendation: Old text: "In order to enable this, it is RECOMMENDED that FEC schemes support the Generic Explicit Source FEC Payload ID format described below." New text: "When this feature is desired, one solution can be for the FEC schemes to support the Generic Explicit Source FEC Payload ID format described below." Opinions? Cheers, Vincent and Ali. From rajiva@cisco.com Fri Feb 11 01:05:17 2011 Return-Path: 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 CA5EA3A6A43 for ; Fri, 11 Feb 2011 01:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 6TuT9ZF5GBCh for ; Fri, 11 Feb 2011 01:05:12 -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 6CB4C3A6921 for ; Fri, 11 Feb 2011 01:05:12 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigBACKKVE2tJXG8/2dsb2JhbACXFo5fc6AWmyyFXASFAYoz X-IronPort-AV: E=Sophos;i="4.60,454,1291593600"; d="scan'208";a="214193095" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rtp-iport-1.cisco.com with ESMTP; 11 Feb 2011 09:05:26 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p1B95P4u008833; Fri, 11 Feb 2011 09:05:25 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Feb 2011 03:05:25 -0600 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: Fri, 11 Feb 2011 03:05:24 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C04182352@XMB-RCD-111.cisco.com> In-Reply-To: <4D54FB32.9070601@inrialpes.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] About the Generic Explicit Source FEC Payload ID Thread-Index: AcvJynTLOb7KbO4NS0OvhyCPsY9+qwAAErkw References: <4D54FB32.9070601@inrialpes.fr> From: "Rajiv Asati (rajiva)" To: "Vincent Roca" , X-OriginalArrivalTime: 11 Feb 2011 09:05:25.0555 (UTC) FILETIME=[D217E830:01CBC9CA] Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload ID 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: , X-List-Received-Date: Fri, 11 Feb 2011 09:05:17 -0000 Vincent, Good point. I suggest option#1. Cheers, Rajiv ~~~ June 8, 2011 is the "World IPv6 Day" (http://isoc.org/wp/worldipv6day/) > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > Behalf Of Vincent Roca > Sent: Friday, February 11, 2011 4:03 AM > To: fecframe@ietf.org > Subject: [Fecframe] About the Generic Explicit Source FEC Payload ID >=20 > Hi everybody, >=20 > While preparing the new O&M section proposal with Ali, > we spotted two points we'd like to discuss. Here is the first > one. >=20 > Point 1: about the "Generic Explicit Source FEC Payload ID" > ------------------------------------------------- >=20 > Section 5.3.1. of the FECFRAME Framework I-D says: >=20 > "In order to apply FEC protection using multiple FEC schemes to a > single source flow, all schemes have to use the same Explicit > Source > FEC Payload ID format. In order to enable this, it is RECOMMENDED > that FEC schemes support the Generic Explicit Source FEC Payload ID > format described below." >=20 > Then it explains what is meant by "Generic source FEC payload ID", > i.e. a two byte field, in network byte order, that contains a sequence > number shared by all FEC schemes. >=20 > When reading 5.3.1, it is clear to me that this field is to be carried > in an **Explicit Source FEC Payload ID**, i.e. at the end of the > packet. > Section 5.3.1 does not suggest to reuse any sequence number that > may exist in the application flow (like the RTP sequence number) to > achieve this goal. >=20 > We also notice that the sentence is rather strong in what FEC Schemes > should define (it says "RECOMMENDED"). >=20 > It turns out that none of the current FEC Schemes define such a > Generic Explicit FEC Payload ID. > Additionally, the only use-case where an application flow is > protected by two different AL-FEC codes and that is considered > by IETF is the DVB-IPTV (draft-ietf-fecframe-dvb-al-fec-04). In > that case the solution consists in reusing the RTP SN field, rather > than defining a "Generic source FEC payload ID". >=20 >=20 > So we see two options here: > 1- Extend section 5.3.1 recommendations so that, if the > application flow already includes a sequence number that > fulfills the requirements of section 5.3.1, then this field can > be used to fulfill the needs specified here. But this is not > strictly speaking a special case of Explicit FEC Payload ID > (nothing is added to source packets). >=20 > 2- or weaken current 5.3.1 recommendation: > Old text: > "In order to enable this, it is RECOMMENDED > that FEC schemes support the Generic Explicit Source FEC > Payload ID > format described below." > New text: > "When this feature is desired, one solution can be for the FEC > schemes > to support the Generic Explicit Source FEC Payload ID format > described > below." >=20 > Opinions? >=20 > Cheers, >=20 > Vincent and Ali. > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From vincent.roca@inrialpes.fr Fri Feb 11 02:13:26 2011 Return-Path: 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 6F19F3A6AE4 for ; Fri, 11 Feb 2011 02:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 CH3QAZUnFJ74 for ; Fri, 11 Feb 2011 02:13:25 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 5DD373A6960 for ; Fri, 11 Feb 2011 02:13:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,454,1291590000"; d="scan'208";a="99707601" Received: from ral022r.vpn.inria.fr ([128.93.178.22]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 11 Feb 2011 11:13:39 +0100 Message-ID: <4D550BC7.8090701@inrialpes.fr> Date: Fri, 11 Feb 2011 11:13:27 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "fecframe@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Fecframe] Managing losses between the sending application and the FECFRAME instance 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: , X-List-Received-Date: Fri, 11 Feb 2011 10:13:26 -0000 And this is point 2: Managing losses between the sending application and the FECFRAME instance --------------------------------------------- It is often implicitly assumed in FEC Schemes that there is no loss between the sending application and the FECFRAME Instance that performs FEC encoding. That's reasonable (we apply FECFRAME on lossy channels) but we should not design solutions that break if ever this happens, no matter the reason. (NB: this may be caused by having FECFRAME on a middlebox whereas the application flow is generated on a remote server. Or perhaps because of strange (bad?) FECFRAME implementations that may loose ADUs, e.g. in case the machine is frozen during a few seconds, or for any other reason, bugs included.) All FEC Schemes that make use of an Explicit Source FEC Payload ID (be it Generic or not ;-)) are safe, since they define their own sequential numbering space. However this is not the case for FEC Schemes that reuse (for instance) the RTP sequence number. In that case, an erasure between the application (therefore RTP) and the FECFRAME Instance creates a gap in the RTP sequence number space that needs to be signaled somehow to the receiver. The simplest way of addressing this situation consists in saying that source block creation needs to consider this possibility and start a new block if ever this happens. Since all the existing FEC Repair Payload IDs for FEC schemes that rely on RTP sequence numbers, signal to the receiver in the FEC Repair Payload ID: - the base RTP SN of the block and - the source block length, that's sufficient. A consequence is that the block size can vary if there are erasures on this path, and this phenomenon is not under control. As an extreme case: ... LOST LOST ... -------------------------------------------> time There's a block that is composed of a single packet (SN=8). That's bad but the FEC Scheme does not break. And of course this situation is the sign that something should be re-considered in the design. So this is an easy fix to the problem, that does not require major changes to current I-D. This discussion is already included in our new O&M proposal, section 10.2, "Within End-Systems vs. within Middleboxes". Opinions? Cheers, Vincent and Ali From abegen@cisco.com Fri Feb 11 06:13:40 2011 Return-Path: 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 4F5EA3A6A19 for ; Fri, 11 Feb 2011 06:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 bKzgPs0Itdp8 for ; Fri, 11 Feb 2011 06:13:39 -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 4B11D3A69A5 for ; Fri, 11 Feb 2011 06:13:39 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBAHnTVE2rR7Hu/2dsb2JhbACXF45dc59GmziFXQSFAYoz X-IronPort-AV: E=Sophos;i="4.60,455,1291593600"; d="scan'208";a="258603665" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2011 14:13:54 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1BEDsFV002195; Fri, 11 Feb 2011 14:13:54 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.4675); Fri, 11 Feb 2011 06:13:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Feb 2011 06:13:52 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7DDB@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D54FB32.9070601@inrialpes.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] About the Generic Explicit Source FEC Payload ID Thread-Index: AcvJynXLnQmMcbB/TJCc4fran0u5xAAKmMdg References: <4D54FB32.9070601@inrialpes.fr> From: "Ali C. Begen (abegen)" To: "Vincent Roca" , X-OriginalArrivalTime: 11 Feb 2011 14:13:54.0135 (UTC) FILETIME=[EA111670:01CBC9F5] Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload ID 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: , X-List-Received-Date: Fri, 11 Feb 2011 14:13:40 -0000 > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Vincent Roca > Sent: Friday, February 11, 2011 4:03 AM > To: fecframe@ietf.org > Subject: [Fecframe] About the Generic Explicit Source FEC Payload ID >=20 > Hi everybody, >=20 > While preparing the new O&M section proposal with Ali, > we spotted two points we'd like to discuss. Here is the first > one. >=20 > Point 1: about the "Generic Explicit Source FEC Payload ID" > ------------------------------------------------- >=20 > Section 5.3.1. of the FECFRAME Framework I-D says: >=20 > "In order to apply FEC protection using multiple FEC schemes to a > single source flow, all schemes have to use the same Explicit = Source > FEC Payload ID format. In order to enable this, it is RECOMMENDED > that FEC schemes support the Generic Explicit Source FEC Payload = ID > format described below." >=20 > Then it explains what is meant by "Generic source FEC payload ID", > i.e. a two byte field, in network byte order, that contains a sequence > number shared by all FEC schemes. >=20 > When reading 5.3.1, it is clear to me that this field is to be carried > in an **Explicit Source FEC Payload ID**, i.e. at the end of the = packet. > Section 5.3.1 does not suggest to reuse any sequence number that > may exist in the application flow (like the RTP sequence number) to > achieve this goal. >=20 > We also notice that the sentence is rather strong in what FEC Schemes > should define (it says "RECOMMENDED"). >=20 > It turns out that none of the current FEC Schemes define such a > Generic Explicit FEC Payload ID. > Additionally, the only use-case where an application flow is > protected by two different AL-FEC codes and that is considered > by IETF is the DVB-IPTV (draft-ietf-fecframe-dvb-al-fec-04). In > that case the solution consists in reusing the RTP SN field, rather > than defining a "Generic source FEC payload ID". >=20 >=20 > So we see two options here: > 1- Extend section 5.3.1 recommendations so that, if the > application flow already includes a sequence number that > fulfills the requirements of section 5.3.1, then this field can > be used to fulfill the needs specified here. But this is not > strictly speaking a special case of Explicit FEC Payload ID > (nothing is added to source packets). Right. If there is a seqnum that can be used, it could be used and no = chances to the source packets at all. If not, we need to specify the = format for the generic source fec payload ID field. And the format we = define in the framework draft is RECOMMENDED to be used when an fec = scheme desires to support being able to be used with other FEC schemes = jointly. In other words, if an FEC scheme chooses a different format for = the explicit source fec payload id, it won't be able to be used with = other FEC schemes that also need an explicit source fec payload id. This = is not interoperability but for greater good, I think we should = RECOMMEND the generic format we will define. -acbegen =20 > 2- or weaken current 5.3.1 recommendation: > Old text: > "In order to enable this, it is RECOMMENDED > that FEC schemes support the Generic Explicit Source FEC > Payload ID > format described below." > New text: > "When this feature is desired, one solution can be for the FEC > schemes > to support the Generic Explicit Source FEC Payload ID format > described > below." >=20 > Opinions? >=20 > Cheers, >=20 > Vincent and Ali. > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Fri Feb 11 06:14:59 2011 Return-Path: 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 10DA73A6A5D for ; Fri, 11 Feb 2011 06:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 FuJVryt-JtrT for ; Fri, 11 Feb 2011 06:14:57 -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 889AA3A6AEE for ; Fri, 11 Feb 2011 06:14:57 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBAALTVE2rR7Ht/2dsb2JhbACXF45dc59BmziCfROCTQSFAYoz X-IronPort-AV: E=Sophos;i="4.60,455,1291593600"; d="scan'208";a="328396531" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2011 14:15:12 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1BEFCLp001433; Fri, 11 Feb 2011 14:15:12 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.4675); Fri, 11 Feb 2011 06:15:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Feb 2011 06:15:09 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7DDD@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Ops/Management Cons. text for fecframe Thread-Index: AcvJX4LOUPpFWWZQSDGUx+2+eq2IFgAHruXhAB3rtbA= References: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7BA9@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Luby, Michael" , X-OriginalArrivalTime: 11 Feb 2011 14:15:12.0337 (UTC) FILETIME=[18ADC410:01CBC9F6] Cc: dromasca@avaya.com, Sean Turner , Russ Housley Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe 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: , X-List-Received-Date: Fri, 11 Feb 2011 14:14:59 -0000 > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Thursday, February 10, 2011 6:57 PM > To: Ali C. Begen (abegen); fecframe@ietf.org > Cc: Sean Turner; Russ Housley; dromasca@avaya.com; Luby, Michael > Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe >=20 > This looks good Ali. One thing to perhaps add at the end of Section = 10.2 is > that if multiple "source flows" are protected by a single FEC repair = stream > (generated from the bundle of the source flows) then it should be the = case > that all of these flows are received by receivers who expect to = receive and > use the FEC repair stream generated from them (as otherwise the source = flows > that are not received will be considered as loss by the receiver, and = also > it might allow the receiver to recover flows that are not meant for it = to > receive, a security concern). Good point. =20 > I guess perhaps it is good to add a general security statement that = says > that it is important to only allow FEC repair be received by receivers = for > which all of the original source from which the FEC repair is = generated can > be received by those receivers. (Otherwise, the receivers might be = able to > recover source flows using FEC repair that they are not supposed to > receive.) Better point. Thanks. -acbegen =20 >=20 > On 2/10/11 12:51 PM, "Ali C. Begen (abegen)" wrote: >=20 > > We have not seen any email from the DISCUSS holders (except David) = regarding > > the framework draft in the mailing list (I did not see any private = email, > > either and for some reason the system is not including me in the = emails from > > IESG). We need to publish this specification as it is holding = several other > > documents, and even the WG itself (Clearly, many of us are eager to = close the > > WG). > > > > Here is a summary of where we stand now: > > > > The DISCUSS from Russ H. is about some inconsistency in section 5, = which was > > fixed 2 versions ago. > > > > The DISCUSS Sean T. is about the security related issues, which were = addressed > > in the last revision. > > > > Russ, Sean, if you still have issues with the revised text, please = raise them. > > > > The DISCUSS from Dan R. and David H. are related to ops/management = issues. We > > had a lot discussion on this in the mailing list, and the text below = attempts > > to reflect the view of the WG on this subject. > > > > We would like to get your (WG individuals but in particular the = DISCUSS > > holders) comments on this text. The sooner the better as we would = like to > > close this issue before the next meeting and ship the draft to the = editor. > > > > Approvals/objections are welcome as usual. > > > > -acbegen > > > > > > 10. Operations and Management Considerations > > > > The question of operating and managing the FEC Framework and the > > associated FEC scheme(s) is of high practical importance. The = goals > > of this section are to discuss the general requirements, aspects > > related to a specific deployment and solutions whenever possible. > > > > In particular, this section discusses the questions of > > interoperability across vendors/use cases and whether defining > > mandatory to implement (but not mandatory to use) solutions is > > beneficial. > > > > 10.1. What are the Key Aspects to Consider? > > > > Several aspects need to be considered since they will directly = impact > > the way the FEC Framework and the associated FEC schemes can be > > operated and managed. > > > > This section lists them as follows: > > > > o A Single Small Generic Component within a Larger (and Often > > Legacy) Solution: The FEC Framework is one component within a > > larger solution which includes both one or several upper-layer > > applications (that generate one or several ADU flows) and an > > underlying protocol stack. A key design principle is that the = FEC > > Framework should be able to work without making any assumption > > with respect to either the upper-layer application(s) or the > > underlying protocol stack, even if there are special cases = where > > assumptions are made. > > > > o One-to-One with Feedback vs. One-to-Many with Feedback vs. = One-to- > > Many without Feedback Scenarios: The FEC Framework can be used = in > > use cases that completely differ from one another. Some use = cases > > are one-way (e.g., in broadcast networks), with either a = one-to- > > one, one-to-many or many-to-many transmission model, and the > > receiver(s) cannot send any feedback to the sender(s). Other = use > > cases follow a bidirectional one-to-one, one-to-many, or = many-to- > > many scenario, and the receiver(s) can send feedback to the > > sender(s). > > > > o Non-FEC Framework Capable Receivers: With the one-to-many and > > many-to-many use cases, the receiver population might have > > different capabilities with respect to the FEC Framework = itself > > and the supported FEC schemes. Some receivers might not be > > capable of decoding the repair packets belonging to a = particular > > FEC scheme, while some other receivers might not be supporting = the > > FEC Framework at all. > > > > o Internet vs. non-Internet Networks: The FEC Framework can be > > useful in many use cases that use a transport network that is = not > > the public Internet (e.g., with IPTV or Mobile TV). In such > > networks, the operational and management considerations can be > > achieved through an open or proprietary solution, which is > > specified outside of the IETF. > > > > o Congestion Control Considerations: See Section 8 for a = discussion > > on whether congestion control is needed or not, and its > > relationships with the FEC Framework. > > > > o Within End-Systems vs. within Middleboxes: The FEC Framework = can > > be used within end-systems, very close to the upper-layer > > application, or within dedicated middleboxes, for instance = when it > > is desired to protect one or several flows while they cross a > > lossy channel between two or more remote sites. > > > > o Protecting a Single Flow vs. Several Flows Globally: The FEC > > Framework can be used to protect a single flow, or several = flows > > globally. > > > > 10.2. Operational and Management Recommendations > > > > Overall, from the discussion of Section 10.1, it is clear that = the > > CDPs and FEC schemes compatible with the FEC Framework widely = differ > > in their capabilities, application and deployment scenarios such = that > > a common operation and management tool that works well for all of > > them does not exist. Thus, as a design choice, the FEC Framework > > does not dictate the use of any particular technology or protocol = for > > transporting FEC data, managing the hosts, signaling the > > configuration information or encoding the configuration = information. > > This provides flexibility and was one of the main goals of the = FEC > > Framework. However, this section gives some recommendations. > > > > o A Single Small Generic Component within a Larger (and Often > > Legacy) Solution: It is anticipated that the FEC Framework = will > > often be used to protect one or several RTP streams. = Therefore, > > there are use cases that may take advantage of RTCP to collect > > feedback information, and one can take advantage of the = associated > > tools to operate and manage the FEC Framework instance along = with > > the associated FEC schemes. > > > > o One-to-One with Feedback vs. One-to-Many with Feedback vs. = One-to- > > Many without Feedback Scenarios: With use cases that are = one-way, > > the FEC Framework sender does not have any way to gather = feedback > > from receivers. With use cases that are bidirectional, the = FEC > > Framework sender can collect detailed feedback (e.g., in case = of a > > one-to-one scenario) or at least occasional feedback (e.g., in > > case of a multicast, one-to-many scenario). All these > > applications have naturally different operational and = management > > aspects. If any, they also have different requirements or > > features for collecting feedback, processing it and acting on = it. > > The data structures for carrying the feedback also vary. > > > > o Non-FEC Framework Capable Receivers: Section 5.3 gives > > recommendations on how to provide backward compatibility in > > presence of receivers that cannot support the FEC scheme being > > used, or the FEC Framework itself: basically the use of = Explicit > > Source FEC Payload ID is banned. Additionally, a non-FEC > > Framework capable receiver MUST also have a means not to = receive > > the repair packets that it will not be able to decode in the = first > > place or a means to identify and discard them appropriately = upon > > receiving them. This can be achieved by sending repair = packets on > > a different transport-layer flow. In case of an RTP source = flow, > > this can also be achieved by using an RTP framing for FEC = repair > > packets with a different payload type. Both source and repair > > packets can then be sent on the same transport-layer flow. It = is > > the responsibility of the sender to select the appropriate > > mechanism when needed. > > > > o Congestion Control Considerations: See Section 8 for a = discussion > > on whether congestion control is needed or not, and its > > relationships with the FEC Framework. > > > > o Within End-Systems vs. within Middleboxes: When the FEC = Framework > > is used within middleboxes, it is RECOMMENDED that the paths > > between the hosts where the sending applications run and the > > middlebox that performs FEC encoding be as reliable as = possible, > > since these paths are not protected against erasures by = default. > > Similarly, it is RECOMMENDED that the paths between the > > middleboxes that perform FEC decoding and the end-systems = where > > the receiving applications operate, in situations where this = is a > > different host, be as reliable as possible since these paths = are > > not protected against losses by default. > > > > The recommendation for the sending side is particularly = important > > with FEC schemes that do not modify the ADU for backward > > compatibility purposes (i.e. do not use any Explicit Source = FEC > > Payload ID) and rely for instance on the RTP sequence number = field > > to identify FEC source packets within their source block. In = this > > case, a loss on this path directly leads to a gap in the RTP > > sequence number space seen by the FECFRAME instance. This = MUST be > > considered during source block creation by the FEC scheme. = With > > FEC schemes that indicate in the Repair FEC Payload ID, for = each > > source block, the base RTP sequence number and number of > > consecutive RTP packets that belong to this source block, an = ADU > > loss requires to switch to a new source block. This SHOULD be > > discussed in the FEC scheme when there is a chance of losing a > > packet. > > > > o Protecting a Single Flow vs. Several Flows Globally: In the > > general case, the various ADU flows that are globally = protected > > can have different features, and in particular different = real-time > > requirements (in case of real-time flows). The process of > > globally protecting these flows SHOULD take into account the > > requirements of each individual flow. In particular, it would = be > > counter-productive to add repair traffic to a real-time flow = for > > which the FEC decoding delay at a receiver makes decoded ADUs = for > > this flow useless because they do not satisfy the associated = real- > > time constraints. From a practical point of view, this means = that > > the source block creation process at the sending FEC Framework > > instance, SHOULD consider the most stringent real-time > > requirements of the ADU flows being globally protected. > > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Fri Feb 11 06:18:10 2011 Return-Path: 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 176FD3A6A19 for ; Fri, 11 Feb 2011 06:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 hDrhyk3j1Szo for ; Fri, 11 Feb 2011 06:18:09 -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 F1DAB3A6A0F for ; Fri, 11 Feb 2011 06:18:08 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBAC3UVE2rR7Hu/2dsb2JhbACXF45dc59PmziFXQSFAYoz X-IronPort-AV: E=Sophos;i="4.60,455,1291593600"; d="scan'208";a="328398273" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2011 14:18:24 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1BEIOmb005399; Fri, 11 Feb 2011 14:18:24 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.4675); Fri, 11 Feb 2011 06:18:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Feb 2011 06:17:39 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7DDE@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D550BC7.8090701@inrialpes.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Managing losses between the sending application and the FECFRAME instance Thread-Index: AcvJ1GA5qyHZf6FXRyy1N3N8Wy6xBwAIblpg References: <4D550BC7.8090701@inrialpes.fr> From: "Ali C. Begen (abegen)" To: "Vincent Roca" , X-OriginalArrivalTime: 11 Feb 2011 14:18:23.0850 (UTC) FILETIME=[8AD454A0:01CBC9F6] Subject: Re: [Fecframe] Managing losses between the sending application and the FECFRAME instance 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: , X-List-Received-Date: Fri, 11 Feb 2011 14:18:10 -0000 > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Vincent Roca > Sent: Friday, February 11, 2011 5:13 AM > To: fecframe@ietf.org > Subject: [Fecframe] Managing losses between the sending application = and the FECFRAME instance >=20 > And this is point 2: >=20 > Managing losses between the sending application and > the FECFRAME instance > --------------------------------------------- >=20 > It is often implicitly assumed in FEC Schemes that there > is no loss between the sending application and the > FECFRAME Instance that performs FEC encoding. That's > reasonable (we apply FECFRAME on lossy channels) > but we should not design solutions that break if ever > this happens, no matter the reason. >=20 > (NB: this may be caused by having FECFRAME on a > middlebox whereas the application flow is generated > on a remote server. Or perhaps because of strange > (bad?) FECFRAME implementations that may loose > ADUs, e.g. in case the machine is frozen during a few > seconds, or for any other reason, bugs included.) >=20 > All FEC Schemes that make use of an Explicit Source > FEC Payload ID (be it Generic or not ;-)) are safe, since > they define their own sequential numbering space. >=20 > However this is not the case for FEC Schemes that reuse > (for instance) the RTP sequence number. In that case, an > erasure between the application (therefore RTP) and > the FECFRAME Instance creates a gap in the RTP sequence > number space that needs to be signaled somehow to the > receiver. >=20 > The simplest way of addressing this situation consists in > saying that source block creation needs to consider this > possibility and start a new block if ever this happens. > Since all the existing FEC Repair Payload IDs for FEC > schemes that rely on RTP sequence numbers, signal to > the receiver in the FEC Repair Payload ID: > - the base RTP SN of the block and > - the source block length, > that's sufficient. I like this fix, but maybe we should add a note. Since this will cause = source block sizes to vary over time, the overhead may also vary over = time. And so this should be a surprise to the sender or receiver. We = should add a small note on this. -acbegen =20 > A consequence is that the block size can vary if there > are erasures on this path, and this phenomenon is not > under control. As an extreme case: >=20 > ... LOST LOST ... > -------------------------------------------> time >=20 > There's a block that is composed of a single packet > (SN=3D8). That's bad but the FEC Scheme does not break. > And of course this situation is the sign that something > should be re-considered in the design. >=20 > So this is an easy fix to the problem, that does not > require major changes to current I-D. >=20 > This discussion is already included in our new O&M > proposal, section 10.2, "Within End-Systems vs. within > Middleboxes". >=20 > Opinions? >=20 > Cheers, >=20 > Vincent and Ali > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From luby@qualcomm.com Fri Feb 11 08:56:09 2011 Return-Path: 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 C2B0D3A69D2 for ; Fri, 11 Feb 2011 08:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 fB9dHrdPGod5 for ; Fri, 11 Feb 2011 08:56:08 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 335123A679C for ; Fri, 11 Feb 2011 08:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1297443383; x=1328979383; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"A li=20C.=20Begen=20(abegen)"=20,=20Vince nt=20Roca=0D=0A=09,=20"fecfram e@ietf.org"=20|Date:=20Fri,=2011=20Feb =202011=2008:56:19=20-0800|Subject:=20Re:=20[Fecframe]=20 Managing=20losses=20between=20the=20sending=20application =20and=0D=0A=20the=20FECFRAME=20instance|Thread-Topic:=20 [Fecframe]=20Managing=20losses=20between=20the=20sending =20application=20and=0D=0A=20the=20FECFRAME=20instance |Thread-Index:=20AcvJ1GA5qyHZf6FXRyy1N3N8Wy6xBwAIblpgAAWg NXE=3D|Message-ID:=20 |In-Reply-To:=20<04CAD96D4C5A3D48B1919248A8FE0D540E4C7DDE @xmb-sjc-215.amer.cisco.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|user-agent:=20Microsoft-Entourage/ 13.8.0.101117|acceptlanguage:=20en-US|Content-Type:=20tex t/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=AgvdcKeCD9KW5SHXj7KXPqi1wIOw2JOlo3s33nTNg8c=; b=BLEtXo3A8LGWj559gElS9L9L08VFU+ninvssVRXVbZbx03xge/upcfvS V4n0fSlpYn+Nuus7/r+octc5Fm2kCdtW22Sh5XKGz8QufbnzdjnkINmZ6 8HytG4YJ8VM45TwyaMMQXqI1gKw8ntkiAvyHE4GiP/KlUi1RItoJpg87m g=; X-IronPort-AV: E=McAfee;i="5400,1158,6253"; a="73872871" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 11 Feb 2011 08:56:23 -0800 X-IronPort-AV: E=Sophos;i="4.60,455,1291622400"; d="scan'208";a="115447429" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 11 Feb 2011 08:56:23 -0800 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhc07.na.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 11 Feb 2011 08:56:22 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Fri, 11 Feb 2011 08:56:22 -0800 From: "Luby, Michael" To: "Ali C. Begen (abegen)" , Vincent Roca , "fecframe@ietf.org" Date: Fri, 11 Feb 2011 08:56:19 -0800 Thread-Topic: [Fecframe] Managing losses between the sending application and the FECFRAME instance Thread-Index: AcvJ1GA5qyHZf6FXRyy1N3N8Wy6xBwAIblpgAAWgNXE= Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7DDE@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Fecframe] Managing losses between the sending application and the FECFRAME instance 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: , X-List-Received-Date: Fri, 11 Feb 2011 16:56:09 -0000 It seems like this is an unbounded problem. What about the case when there is out of order packet delivery, that can cause the mechanism below to cut = a source block and then start a new one packet source block, etc. There are also cases where the receivers cannot handle variable sized sourc= e blocks (they are expecting exactly so many packets of a fixed size per source block), e.g., because that is how the FEC scheme is defined. The solution proposed doesn't work for this case as well (it will really mess u= p the receivers). I think a better approach is that all the packets from the original source either MUST or SHOULD reach the FEC encoder in their proper sequence. What happens when that is not true seems to be an unbounded problem, and I don't think we can solve it (out of scope of the specification). On 2/11/11 6:17 AM, "Ali C. Begen (abegen)" wrote: >=20 >=20 >> -----Original Message----- >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Be= half >> Of Vincent Roca >> Sent: Friday, February 11, 2011 5:13 AM >> To: fecframe@ietf.org >> Subject: [Fecframe] Managing losses between the sending application and = the >> FECFRAME instance >>=20 >> And this is point 2: >>=20 >> Managing losses between the sending application and >> the FECFRAME instance >> --------------------------------------------- >>=20 >> It is often implicitly assumed in FEC Schemes that there >> is no loss between the sending application and the >> FECFRAME Instance that performs FEC encoding. That's >> reasonable (we apply FECFRAME on lossy channels) >> but we should not design solutions that break if ever >> this happens, no matter the reason. >>=20 >> (NB: this may be caused by having FECFRAME on a >> middlebox whereas the application flow is generated >> on a remote server. Or perhaps because of strange >> (bad?) FECFRAME implementations that may loose >> ADUs, e.g. in case the machine is frozen during a few >> seconds, or for any other reason, bugs included.) >>=20 >> All FEC Schemes that make use of an Explicit Source >> FEC Payload ID (be it Generic or not ;-)) are safe, since >> they define their own sequential numbering space. >>=20 >> However this is not the case for FEC Schemes that reuse >> (for instance) the RTP sequence number. In that case, an >> erasure between the application (therefore RTP) and >> the FECFRAME Instance creates a gap in the RTP sequence >> number space that needs to be signaled somehow to the >> receiver. >>=20 >> The simplest way of addressing this situation consists in >> saying that source block creation needs to consider this >> possibility and start a new block if ever this happens. >> Since all the existing FEC Repair Payload IDs for FEC >> schemes that rely on RTP sequence numbers, signal to >> the receiver in the FEC Repair Payload ID: >> - the base RTP SN of the block and >> - the source block length, >> that's sufficient. >=20 > I like this fix, but maybe we should add a note. Since this will cause so= urce > block sizes to vary over time, the overhead may also vary over time. And = so > this should be a surprise to the sender or receiver. We should add a smal= l > note on this. >=20 > -acbegen > =20 >> A consequence is that the block size can vary if there >> are erasures on this path, and this phenomenon is not >> under control. As an extreme case: >>=20 >> ... LOST LOST ... >> -------------------------------------------> time >>=20 >> There's a block that is composed of a single packet >> (SN=3D8). That's bad but the FEC Scheme does not break. >> And of course this situation is the sign that something >> should be re-considered in the design. >>=20 >> So this is an easy fix to the problem, that does not >> require major changes to current I-D. >>=20 >> This discussion is already included in our new O&M >> proposal, section 10.2, "Within End-Systems vs. within >> Middleboxes". >>=20 >> Opinions? >>=20 >> Cheers, >>=20 >> Vincent and Ali >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Fri Feb 11 09:03:35 2011 Return-Path: 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 159073A6956 for ; Fri, 11 Feb 2011 09:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 E0ogkvXBko3Y for ; Fri, 11 Feb 2011 09:03:33 -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 5D4E23A69D2 for ; Fri, 11 Feb 2011 09:03:33 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBAM/6VE2rR7Hu/2dsb2JhbACXF45dc59NmzeFXQSFAYoz X-IronPort-AV: E=Sophos;i="4.60,456,1291593600"; d="scan'208";a="661790866" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 11 Feb 2011 17:03:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1BH3meN015817; Fri, 11 Feb 2011 17:03:48 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.4675); Fri, 11 Feb 2011 09:03:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Feb 2011 09:03:16 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7E68@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Managing losses between the sending application and the FECFRAME instance Thread-Index: AcvJ1GA5qyHZf6FXRyy1N3N8Wy6xBwAIblpgAAWgNXEAAB0s4A== References: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7DDE@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Luby, Michael" , "Vincent Roca" , X-OriginalArrivalTime: 11 Feb 2011 17:03:48.0598 (UTC) FILETIME=[A670B160:01CBCA0D] Subject: Re: [Fecframe] Managing losses between the sending application and the FECFRAME instance 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: , X-List-Received-Date: Fri, 11 Feb 2011 17:03:35 -0000 > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Friday, February 11, 2011 11:56 AM > To: Ali C. Begen (abegen); Vincent Roca; fecframe@ietf.org > Subject: Re: [Fecframe] Managing losses between the sending = application and the FECFRAME instance >=20 > It seems like this is an unbounded problem. What about the case when = there > is out of order packet delivery, that can cause the mechanism below to = cut a > source block and then start a new one packet source block, etc. Yup, packet loss or re-ordering can be dealt with to some extent but = beyond the limit, the fecframe sender will continue with what it has. =20 > There are also cases where the receivers cannot handle variable sized = source > blocks (they are expecting exactly so many packets of a fixed size per > source block), e.g., because that is how the FEC scheme is defined. = The > solution proposed doesn't work for this case as well (it will really = mess up > the receivers). Also, true but in that case, one needs to make sure the fecframe sender = will not see any gaps in the source packets. =20 > I think a better approach is that all the packets from the original = source > either MUST or SHOULD reach the FEC encoder in their proper sequence. = What And within a desired delay. > happens when that is not true seems to be an unbounded problem, and I = don't > think we can solve it (out of scope of the specification). Then, we make the recommendation above (I guess I prefer SHOULD) but = then add that the fecframe sender/receiver implementation needs to = consider the impact of such problems. =20 -acbegen >=20 > On 2/11/11 6:17 AM, "Ali C. Begen (abegen)" wrote: >=20 > > > > > >> -----Original Message----- > >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] = On Behalf > >> Of Vincent Roca > >> Sent: Friday, February 11, 2011 5:13 AM > >> To: fecframe@ietf.org > >> Subject: [Fecframe] Managing losses between the sending application = and the > >> FECFRAME instance > >> > >> And this is point 2: > >> > >> Managing losses between the sending application and > >> the FECFRAME instance > >> --------------------------------------------- > >> > >> It is often implicitly assumed in FEC Schemes that there > >> is no loss between the sending application and the > >> FECFRAME Instance that performs FEC encoding. That's > >> reasonable (we apply FECFRAME on lossy channels) > >> but we should not design solutions that break if ever > >> this happens, no matter the reason. > >> > >> (NB: this may be caused by having FECFRAME on a > >> middlebox whereas the application flow is generated > >> on a remote server. Or perhaps because of strange > >> (bad?) FECFRAME implementations that may loose > >> ADUs, e.g. in case the machine is frozen during a few > >> seconds, or for any other reason, bugs included.) > >> > >> All FEC Schemes that make use of an Explicit Source > >> FEC Payload ID (be it Generic or not ;-)) are safe, since > >> they define their own sequential numbering space. > >> > >> However this is not the case for FEC Schemes that reuse > >> (for instance) the RTP sequence number. In that case, an > >> erasure between the application (therefore RTP) and > >> the FECFRAME Instance creates a gap in the RTP sequence > >> number space that needs to be signaled somehow to the > >> receiver. > >> > >> The simplest way of addressing this situation consists in > >> saying that source block creation needs to consider this > >> possibility and start a new block if ever this happens. > >> Since all the existing FEC Repair Payload IDs for FEC > >> schemes that rely on RTP sequence numbers, signal to > >> the receiver in the FEC Repair Payload ID: > >> - the base RTP SN of the block and > >> - the source block length, > >> that's sufficient. > > > > I like this fix, but maybe we should add a note. Since this will = cause source > > block sizes to vary over time, the overhead may also vary over time. = And so > > this should be a surprise to the sender or receiver. We should add a = small > > note on this. > > > > -acbegen > > > >> A consequence is that the block size can vary if there > >> are erasures on this path, and this phenomenon is not > >> under control. As an extreme case: > >> > >> ... LOST LOST ... > >> -------------------------------------------> time > >> > >> There's a block that is composed of a single packet > >> (SN=3D8). That's bad but the FEC Scheme does not break. > >> And of course this situation is the sign that something > >> should be re-considered in the design. > >> > >> So this is an easy fix to the problem, that does not > >> require major changes to current I-D. > >> > >> This discussion is already included in our new O&M > >> proposal, section 10.2, "Within End-Systems vs. within > >> Middleboxes". > >> > >> Opinions? > >> > >> Cheers, > >> > >> Vincent and Ali > >> _______________________________________________ > >> Fecframe mailing list > >> Fecframe@ietf.org > >> https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe From stephen.botzko@gmail.com Fri Feb 11 10:53:53 2011 Return-Path: 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 BE3973A691E for ; Fri, 11 Feb 2011 10:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 8CG-ULR1ooiJ for ; Fri, 11 Feb 2011 10:53:52 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id C30CA3A659A for ; Fri, 11 Feb 2011 10:53:51 -0800 (PST) Received: by vxi40 with SMTP id 40so1629993vxi.31 for ; Fri, 11 Feb 2011 10:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WI8/1WXS5ECwL/TRWxwPrmnR2GOnOZa/W69Y8BNdJq8=; b=P8f+5PQmH6uUAtdR1XumrTHpnk6MrSewIzpEvXrcO6Pyy6MldvA22goa7rvUjZdD3d tkaoB6DMnnrPp+f6GxMEdDhlHwrYW0Eynd0fxuHXZpQiMpFt9xnWs7S9pG0cPgno1LnR M151WqFjhaQiG+E9F1fFT9+2RfHo1n6BeOiy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZmHRm2eFKD3QkZqO3IbaCz9rHfaj/O6zkewWlbTUeEbZIIAZ4RpBJRN8LyexUsRhh5 v7LODAT75LYwY/89430pX7VSQCYhP6RPUlg+GLzW20uNugQ8UkIvjFyknEXSHBek0hC4 s+UQp/mk7xhALN4qeIITo8xdF00HjLSEVb1mU= MIME-Version: 1.0 Received: by 10.220.200.13 with SMTP id eu13mr1033411vcb.148.1297450446700; Fri, 11 Feb 2011 10:54:06 -0800 (PST) Received: by 10.220.128.30 with HTTP; Fri, 11 Feb 2011 10:54:06 -0800 (PST) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7E68@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7DDE@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540E4C7E68@xmb-sjc-215.amer.cisco.com> Date: Fri, 11 Feb 2011 13:54:06 -0500 Message-ID: From: Stephen Botzko To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=90e6ba539fb4fd457c049c063812 Cc: fecframe@ietf.org Subject: Re: [Fecframe] Managing losses between the sending application and the FECFRAME instance 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: , X-List-Received-Date: Fri, 11 Feb 2011 18:53:53 -0000 --90e6ba539fb4fd457c049c063812 Content-Type: text/plain; charset=ISO-8859-1 RTP retransmission may also be useful in such cases (source to FECFRAME instance) , if the delay increase is acceptable. That might be worth noting. Stephen Botzko On Fri, Feb 11, 2011 at 12:03 PM, Ali C. Begen (abegen) wrote: > > > > -----Original Message----- > > From: Luby, Michael [mailto:luby@qualcomm.com] > > Sent: Friday, February 11, 2011 11:56 AM > > To: Ali C. Begen (abegen); Vincent Roca; fecframe@ietf.org > > Subject: Re: [Fecframe] Managing losses between the sending application > and the FECFRAME instance > > > > It seems like this is an unbounded problem. What about the case when > there > > is out of order packet delivery, that can cause the mechanism below to > cut a > > source block and then start a new one packet source block, etc. > > Yup, packet loss or re-ordering can be dealt with to some extent but beyond > the limit, the fecframe sender will continue with what it has. > > > There are also cases where the receivers cannot handle variable sized > source > > blocks (they are expecting exactly so many packets of a fixed size per > > source block), e.g., because that is how the FEC scheme is defined. The > > solution proposed doesn't work for this case as well (it will really mess > up > > the receivers). > > Also, true but in that case, one needs to make sure the fecframe sender > will not see any gaps in the source packets. > > > I think a better approach is that all the packets from the original > source > > either MUST or SHOULD reach the FEC encoder in their proper sequence. > What > > And within a desired delay. > > > happens when that is not true seems to be an unbounded problem, and I > don't > > think we can solve it (out of scope of the specification). > > Then, we make the recommendation above (I guess I prefer SHOULD) but then > add that the fecframe sender/receiver implementation needs to consider the > impact of such problems. > > -acbegen > > > > > On 2/11/11 6:17 AM, "Ali C. Begen (abegen)" wrote: > > > > > > > > > > >> -----Original Message----- > > >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > Behalf > > >> Of Vincent Roca > > >> Sent: Friday, February 11, 2011 5:13 AM > > >> To: fecframe@ietf.org > > >> Subject: [Fecframe] Managing losses between the sending application > and the > > >> FECFRAME instance > > >> > > >> And this is point 2: > > >> > > >> Managing losses between the sending application and > > >> the FECFRAME instance > > >> --------------------------------------------- > > >> > > >> It is often implicitly assumed in FEC Schemes that there > > >> is no loss between the sending application and the > > >> FECFRAME Instance that performs FEC encoding. That's > > >> reasonable (we apply FECFRAME on lossy channels) > > >> but we should not design solutions that break if ever > > >> this happens, no matter the reason. > > >> > > >> (NB: this may be caused by having FECFRAME on a > > >> middlebox whereas the application flow is generated > > >> on a remote server. Or perhaps because of strange > > >> (bad?) FECFRAME implementations that may loose > > >> ADUs, e.g. in case the machine is frozen during a few > > >> seconds, or for any other reason, bugs included.) > > >> > > >> All FEC Schemes that make use of an Explicit Source > > >> FEC Payload ID (be it Generic or not ;-)) are safe, since > > >> they define their own sequential numbering space. > > >> > > >> However this is not the case for FEC Schemes that reuse > > >> (for instance) the RTP sequence number. In that case, an > > >> erasure between the application (therefore RTP) and > > >> the FECFRAME Instance creates a gap in the RTP sequence > > >> number space that needs to be signaled somehow to the > > >> receiver. > > >> > > >> The simplest way of addressing this situation consists in > > >> saying that source block creation needs to consider this > > >> possibility and start a new block if ever this happens. > > >> Since all the existing FEC Repair Payload IDs for FEC > > >> schemes that rely on RTP sequence numbers, signal to > > >> the receiver in the FEC Repair Payload ID: > > >> - the base RTP SN of the block and > > >> - the source block length, > > >> that's sufficient. > > > > > > I like this fix, but maybe we should add a note. Since this will cause > source > > > block sizes to vary over time, the overhead may also vary over time. > And so > > > this should be a surprise to the sender or receiver. We should add a > small > > > note on this. > > > > > > -acbegen > > > > > >> A consequence is that the block size can vary if there > > >> are erasures on this path, and this phenomenon is not > > >> under control. As an extreme case: > > >> > > >> ... LOST LOST ... > > >> -------------------------------------------> time > > >> > > >> There's a block that is composed of a single packet > > >> (SN=8). That's bad but the FEC Scheme does not break. > > >> And of course this situation is the sign that something > > >> should be re-considered in the design. > > >> > > >> So this is an easy fix to the problem, that does not > > >> require major changes to current I-D. > > >> > > >> This discussion is already included in our new O&M > > >> proposal, section 10.2, "Within End-Systems vs. within > > >> Middleboxes". > > >> > > >> Opinions? > > >> > > >> Cheers, > > >> > > >> Vincent and Ali > > >> _______________________________________________ > > >> Fecframe mailing list > > >> Fecframe@ietf.org > > >> https://www.ietf.org/mailman/listinfo/fecframe > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > --90e6ba539fb4fd457c049c063812 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RTP retransmission may also be useful in such cases (source to FECFRAME ins= tance) , if the delay increase is acceptable.=A0 That might be worth noting= .

Stephen Botzko

On Fri, Feb 11, 2= 011 at 12:03 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:


> -----Original Message-----
> From: Luby, Michael [mailto:luby@= qualcomm.com]
> Sent: Friday, February 11, 2011 11:56 AM
> To: Ali C. Begen (abegen); Vincent Roca; fecframe@ietf.org
> Subject: Re: [Fecframe] Managing losses between the sending applicatio= n and the FECFRAME instance
>
> It seems like this is an unbounded problem. =A0What about the case whe= n there
> is out of order packet delivery, that can cause the mechanism below to= cut a
> source block and then start a new one packet source block, etc.

Yup, packet loss or re-ordering can be dealt with to some extent but = beyond the limit, the fecframe sender will continue with what it has.

> There are also cases where the receivers cannot handle variable sized = source
> blocks (they are expecting exactly so many packets of a fixed size per=
> source block), e.g., because that is how the FEC scheme is defined. = =A0The
> solution proposed doesn't work for this case as well (it will real= ly mess up
> the receivers).

Also, true but in that case, one needs to make sure the fecframe send= er will not see any gaps in the source packets.

> I think a better approach is that all the packets from the original so= urce
> either MUST or SHOULD reach the FEC encoder in their proper sequence. = =A0What

And within a desired delay.

> happens when that is not true seems to be an unbounded problem, and I = don't
> think we can solve it (out of scope of the specification).

Then, we make the recommendation above (I guess I prefer SHOULD) but = then add that the fecframe sender/receiver implementation needs to consider= the impact of such problems.

-acbegen

>
> On 2/11/11 6:17 AM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: fecframe-b= ounces@ietf.org [mailto:fe= cframe-bounces@ietf.org] On Behalf
> >> Of Vincent Roca
> >> Sent: Friday, February 11, 2011 5:13 AM
> >> To: fecframe@ietf.org
> >> Subject: [Fecframe] Managing losses between the sending appli= cation and the
> >> FECFRAME instance
> >>
> >> And this is point 2:
> >>
> >> Managing losses between the sending application and
> >> the FECFRAME instance
> >> ---------------------------------------------
> >>
> >> It is often implicitly assumed in FEC Schemes that there
> >> is no loss between the sending application and the
> >> FECFRAME Instance that performs FEC encoding. That's
> >> reasonable (we apply FECFRAME on lossy channels)
> >> but we should not design solutions that break if ever
> >> this happens, no matter the reason.
> >>
> >> (NB: this may be caused by having FECFRAME on a
> >> middlebox whereas the application flow is generated
> >> on a remote server. Or perhaps because of strange
> >> (bad?) FECFRAME implementations that may loose
> >> ADUs, e.g. in case the machine is frozen during a few
> >> seconds, or for any other reason, bugs included.)
> >>
> >> All FEC Schemes that make use of an Explicit Source
> >> FEC Payload ID (be it Generic or not ;-)) are safe, since
> >> they define their own sequential numbering space.
> >>
> >> However this is not the case for FEC Schemes that reuse
> >> (for instance) the RTP sequence number. In that case, an
> >> erasure between the application (therefore RTP) and
> >> the FECFRAME Instance creates a gap in the RTP sequence
> >> number space that needs to be signaled somehow to the
> >> receiver.
> >>
> >> The simplest way of addressing this situation consists in
> >> saying that source block creation needs to consider this
> >> possibility and start a new block if ever this happens.
> >> Since all the existing FEC Repair Payload IDs for FEC
> >> schemes that rely on RTP sequence numbers, signal to
> >> the receiver in the FEC Repair Payload ID:
> >> =A0 - the base RTP SN of the block and
> >> =A0 - the source block length,
> >> that's sufficient.
> >
> > I like this fix, but maybe we should add a note. Since this will = cause source
> > block sizes to vary over time, the overhead may also vary over ti= me. And so
> > this should be a surprise to the sender or receiver. We should ad= d a small
> > note on this.
> >
> > -acbegen
> >
> >> A consequence is that the block size can vary if there
> >> are erasures on this path, and this phenomenon is not
> >> under control. As an extreme case:
> >>
> >> ...<pkt SN=3D6> LOST <pkt SN=3D8> LOST <pkt SN= =3D10>...
> >> -------------------------------------------> time
> >>
> >> There's a block that is composed of a single packet
> >> (SN=3D8). That's bad but the FEC Scheme does not break. > >> And of course this situation is the sign that something
> >> should be re-considered in the design.
> >>
> >> So this is an easy fix to the problem, that does not
> >> require major changes to current I-D.
> >>
> >> This discussion is already included in our new O&M
> >> proposal, section 10.2, "Within End-Systems vs. within > >> Middleboxes".
> >>
> >> Opinions?
> >>
> >> Cheers,
> >>
> >> =A0 =A0 Vincent and Ali
> >> _______________________________________________
> >> Fecframe mailing list
> >> Fecframe@ietf.org > >> https://www.ietf.org/mailman/listinfo/fecframe
> > _______________________________________________
> > Fecframe mailing list
> > Fecframe@ietf.org
> > https://www.ietf.org/mailman/listinfo/fecframe

_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecframe

--90e6ba539fb4fd457c049c063812-- From luby@qualcomm.com Fri Feb 11 11:40:46 2011 Return-Path: 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 D64043A6A36 for ; Fri, 11 Feb 2011 11:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 NiuINwzl3304 for ; Fri, 11 Feb 2011 11:40:45 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 72C193A6A35 for ; Fri, 11 Feb 2011 11:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1297453261; x=1328989261; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"A li=20C.=20Begen=20(abegen)"=20,=20Vince nt=20Roca=0D=0A=09,=20"fecfram e@ietf.org"=20|Date:=20Fri,=2011=20Feb =202011=2011:40:58=20-0800|Subject:=20Re:=20[Fecframe]=20 Managing=20losses=20between=20the=20sending=20application =20and=0D=0A=20the=20FECFRAME=20instance|Thread-Topic:=20 [Fecframe]=20Managing=20losses=20between=20the=20sending =20application=20and=0D=0A=20the=20FECFRAME=20instance |Thread-Index:=20AcvJ1GA5qyHZf6FXRyy1N3N8Wy6xBwAIblpgAAWg NXEAAB0s4AAFoupe|Message-ID:=20|In-Reply-To:=20<04CAD96D4C5A3D48B1919248A8FE0D540 E4C7E68@xmb-sjc-215.amer.cisco.com>|Accept-Language:=20en -US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|user-agent:=20Microsoft-Entourage/ 13.8.0.101117|acceptlanguage:=20en-US|Content-Type:=20tex t/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=46bV7YFZZT0JzysM/ERGmH4wXN6+B0wMV9gtuIiWGcM=; b=leYFVWW93EMiLx1vRPmSvupMx0BcD4nqQ0GwQPcJb3TXqqUTmHU0vYsM 04O94jK+5UaHmT2o5oeIoRyo5fy5eiKcSAwKKHjesGchiJV/BBP4KQWql GWtQTagMSoVmcNrs6hWEDbgg+HwSkPJRllnBq0eZ/zF32VRe1f3UV9xv2 I=; X-IronPort-AV: E=McAfee;i="5400,1158,6254"; a="74100755" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 11 Feb 2011 11:41:00 -0800 X-IronPort-AV: E=Sophos;i="4.60,455,1291622400"; d="scan'208";a="29503041" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 11 Feb 2011 11:41:00 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 11 Feb 2011 11:41:00 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Fri, 11 Feb 2011 11:40:45 -0800 From: "Luby, Michael" To: "Ali C. Begen (abegen)" , Vincent Roca , "fecframe@ietf.org" Date: Fri, 11 Feb 2011 11:40:58 -0800 Thread-Topic: [Fecframe] Managing losses between the sending application and the FECFRAME instance Thread-Index: AcvJ1GA5qyHZf6FXRyy1N3N8Wy6xBwAIblpgAAWgNXEAAB0s4AAFoupe Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7E68@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Fecframe] Managing losses between the sending application and the FECFRAME instance 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: , X-List-Received-Date: Fri, 11 Feb 2011 19:40:46 -0000 I also agree with the comments about timing considerations, i.e., many receivers need to receive packets for a source block within a certain time window, as otherwise they are useless, and this has an impact on how the FE= C sender operates. On 2/11/11 9:03 AM, "Ali C. Begen (abegen)" wrote: >=20 >=20 >> -----Original Message----- >> From: Luby, Michael [mailto:luby@qualcomm.com] >> Sent: Friday, February 11, 2011 11:56 AM >> To: Ali C. Begen (abegen); Vincent Roca; fecframe@ietf.org >> Subject: Re: [Fecframe] Managing losses between the sending application = and >> the FECFRAME instance >>=20 >> It seems like this is an unbounded problem. What about the case when th= ere >> is out of order packet delivery, that can cause the mechanism below to c= ut a >> source block and then start a new one packet source block, etc. >=20 > Yup, packet loss or re-ordering can be dealt with to some extent but beyo= nd > the limit, the fecframe sender will continue with what it has. > =20 >> There are also cases where the receivers cannot handle variable sized so= urce >> blocks (they are expecting exactly so many packets of a fixed size per >> source block), e.g., because that is how the FEC scheme is defined. The >> solution proposed doesn't work for this case as well (it will really mes= s up >> the receivers). >=20 > Also, true but in that case, one needs to make sure the fecframe sender w= ill > not see any gaps in the source packets. > =20 >> I think a better approach is that all the packets from the original sour= ce >> either MUST or SHOULD reach the FEC encoder in their proper sequence. W= hat >=20 > And within a desired delay. >=20 >> happens when that is not true seems to be an unbounded problem, and I do= n't >> think we can solve it (out of scope of the specification). >=20 > Then, we make the recommendation above (I guess I prefer SHOULD) but then= add > that the fecframe sender/receiver implementation needs to consider the im= pact > of such problems. > =20 > -acbegen >=20 >>=20 >> On 2/11/11 6:17 AM, "Ali C. Begen (abegen)" wrote: >>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On >>>> Behalf >>>> Of Vincent Roca >>>> Sent: Friday, February 11, 2011 5:13 AM >>>> To: fecframe@ietf.org >>>> Subject: [Fecframe] Managing losses between the sending application an= d the >>>> FECFRAME instance >>>>=20 >>>> And this is point 2: >>>>=20 >>>> Managing losses between the sending application and >>>> the FECFRAME instance >>>> --------------------------------------------- >>>>=20 >>>> It is often implicitly assumed in FEC Schemes that there >>>> is no loss between the sending application and the >>>> FECFRAME Instance that performs FEC encoding. That's >>>> reasonable (we apply FECFRAME on lossy channels) >>>> but we should not design solutions that break if ever >>>> this happens, no matter the reason. >>>>=20 >>>> (NB: this may be caused by having FECFRAME on a >>>> middlebox whereas the application flow is generated >>>> on a remote server. Or perhaps because of strange >>>> (bad?) FECFRAME implementations that may loose >>>> ADUs, e.g. in case the machine is frozen during a few >>>> seconds, or for any other reason, bugs included.) >>>>=20 >>>> All FEC Schemes that make use of an Explicit Source >>>> FEC Payload ID (be it Generic or not ;-)) are safe, since >>>> they define their own sequential numbering space. >>>>=20 >>>> However this is not the case for FEC Schemes that reuse >>>> (for instance) the RTP sequence number. In that case, an >>>> erasure between the application (therefore RTP) and >>>> the FECFRAME Instance creates a gap in the RTP sequence >>>> number space that needs to be signaled somehow to the >>>> receiver. >>>>=20 >>>> The simplest way of addressing this situation consists in >>>> saying that source block creation needs to consider this >>>> possibility and start a new block if ever this happens. >>>> Since all the existing FEC Repair Payload IDs for FEC >>>> schemes that rely on RTP sequence numbers, signal to >>>> the receiver in the FEC Repair Payload ID: >>>> - the base RTP SN of the block and >>>> - the source block length, >>>> that's sufficient. >>>=20 >>> I like this fix, but maybe we should add a note. Since this will cause >>> source >>> block sizes to vary over time, the overhead may also vary over time. An= d so >>> this should be a surprise to the sender or receiver. We should add a sm= all >>> note on this. >>>=20 >>> -acbegen >>>=20 >>>> A consequence is that the block size can vary if there >>>> are erasures on this path, and this phenomenon is not >>>> under control. As an extreme case: >>>>=20 >>>> ... LOST LOST ... >>>> -------------------------------------------> time >>>>=20 >>>> There's a block that is composed of a single packet >>>> (SN=3D8). That's bad but the FEC Scheme does not break. >>>> And of course this situation is the sign that something >>>> should be re-considered in the design. >>>>=20 >>>> So this is an easy fix to the problem, that does not >>>> require major changes to current I-D. >>>>=20 >>>> This discussion is already included in our new O&M >>>> proposal, section 10.2, "Within End-Systems vs. within >>>> Middleboxes". >>>>=20 >>>> Opinions? >>>>=20 >>>> Cheers, >>>>=20 >>>> Vincent and Ali >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fecframe >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >=20 From vincent.roca@inrialpes.fr Fri Feb 11 13:40:41 2011 Return-Path: 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 445B43A6A04 for ; Fri, 11 Feb 2011 13:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.18 X-Spam-Level: X-Spam-Status: No, score=-9.18 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 1SZKZ0zsQvOG for ; Fri, 11 Feb 2011 13:40:39 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 1174F3A69F5 for ; Fri, 11 Feb 2011 13:40:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,458,1291590000"; d="scan'208";a="87893001" Received: from unknown (HELO macbook-de-roca.local) ([78.250.85.244]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 11 Feb 2011 22:40:52 +0100 Message-ID: <4D553D18.2050106@inrialpes.fr> Date: Fri, 11 Feb 2011 14:43:52 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Luby, Michael" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dromasca@avaya.com" , Sean Turner , Russ Housley , "fecframe@ietf.org" Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe 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: , X-List-Received-Date: Fri, 11 Feb 2011 21:40:41 -0000 Hello Mike, That's an important operational aspect that we omitted, I agree. I suggest to add the following text as you suggest: --- ADU Flow Bundle Definition and Flow Delivery Considerations: By design a repair flow may enable a receiver to recover the ADU flow(s) that it protects even if none of the associated FEC source packet is received. Therefore, when defining the bundle of ADU flows that are globally protected and when defining which receiver receives which flow, the repair flow(s) SHOULD only be received by receivers that are authorized to receive all the associated ADU flows. See Section 9.4 for additional recommendations for situations where a strict access control to ADU flows is needed. Additionally when multiple ADU flows are globally protected, a receiver who wants to benefit from FECFRAME loss protection SHOULD receive all the ADU flows of the bundle. Otherwise the missing FEC source packets would be considered as lost which may significantly reduce the efficiency of the FEC Scheme. --- Cheers, Vincent On 11/02/11 00:57, Luby, Michael wrote: > This looks good Ali. One thing to perhaps add at the end of Section 10.2 is > that if multiple "source flows" are protected by a single FEC repair stream > (generated from the bundle of the source flows) then it should be the case > that all of these flows are received by receivers who expect to receive and > use the FEC repair stream generated from them (as otherwise the source flows > that are not received will be considered as loss by the receiver, and also > it might allow the receiver to recover flows that are not meant for it to > receive, a security concern). > > I guess perhaps it is good to add a general security statement that says > that it is important to only allow FEC repair be received by receivers for > which all of the original source from which the FEC repair is generated can > be received by those receivers. (Otherwise, the receivers might be able to > recover source flows using FEC repair that they are not supposed to > receive.) > > > On 2/10/11 12:51 PM, "Ali C. Begen (abegen)" wrote: > >> We have not seen any email from the DISCUSS holders (except David) regarding >> the framework draft in the mailing list (I did not see any private email, >> either and for some reason the system is not including me in the emails from >> IESG). We need to publish this specification as it is holding several other >> documents, and even the WG itself (Clearly, many of us are eager to close the >> WG). >> >> Here is a summary of where we stand now: >> >> The DISCUSS from Russ H. is about some inconsistency in section 5, which was >> fixed 2 versions ago. >> >> The DISCUSS Sean T. is about the security related issues, which were addressed >> in the last revision. >> >> Russ, Sean, if you still have issues with the revised text, please raise them. >> >> The DISCUSS from Dan R. and David H. are related to ops/management issues. We >> had a lot discussion on this in the mailing list, and the text below attempts >> to reflect the view of the WG on this subject. >> >> We would like to get your (WG individuals but in particular the DISCUSS >> holders) comments on this text. The sooner the better as we would like to >> close this issue before the next meeting and ship the draft to the editor. >> >> Approvals/objections are welcome as usual. >> >> -acbegen >> >> >> 10. Operations and Management Considerations >> >> The question of operating and managing the FEC Framework and the >> associated FEC scheme(s) is of high practical importance. The goals >> of this section are to discuss the general requirements, aspects >> related to a specific deployment and solutions whenever possible. >> >> In particular, this section discusses the questions of >> interoperability across vendors/use cases and whether defining >> mandatory to implement (but not mandatory to use) solutions is >> beneficial. >> >> 10.1. What are the Key Aspects to Consider? >> >> Several aspects need to be considered since they will directly impact >> the way the FEC Framework and the associated FEC schemes can be >> operated and managed. >> >> This section lists them as follows: >> >> o A Single Small Generic Component within a Larger (and Often >> Legacy) Solution: The FEC Framework is one component within a >> larger solution which includes both one or several upper-layer >> applications (that generate one or several ADU flows) and an >> underlying protocol stack. A key design principle is that the FEC >> Framework should be able to work without making any assumption >> with respect to either the upper-layer application(s) or the >> underlying protocol stack, even if there are special cases where >> assumptions are made. >> >> o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to- >> Many without Feedback Scenarios: The FEC Framework can be used in >> use cases that completely differ from one another. Some use cases >> are one-way (e.g., in broadcast networks), with either a one-to- >> one, one-to-many or many-to-many transmission model, and the >> receiver(s) cannot send any feedback to the sender(s). Other use >> cases follow a bidirectional one-to-one, one-to-many, or many-to- >> many scenario, and the receiver(s) can send feedback to the >> sender(s). >> >> o Non-FEC Framework Capable Receivers: With the one-to-many and >> many-to-many use cases, the receiver population might have >> different capabilities with respect to the FEC Framework itself >> and the supported FEC schemes. Some receivers might not be >> capable of decoding the repair packets belonging to a particular >> FEC scheme, while some other receivers might not be supporting the >> FEC Framework at all. >> >> o Internet vs. non-Internet Networks: The FEC Framework can be >> useful in many use cases that use a transport network that is not >> the public Internet (e.g., with IPTV or Mobile TV). In such >> networks, the operational and management considerations can be >> achieved through an open or proprietary solution, which is >> specified outside of the IETF. >> >> o Congestion Control Considerations: See Section 8 for a discussion >> on whether congestion control is needed or not, and its >> relationships with the FEC Framework. >> >> o Within End-Systems vs. within Middleboxes: The FEC Framework can >> be used within end-systems, very close to the upper-layer >> application, or within dedicated middleboxes, for instance when it >> is desired to protect one or several flows while they cross a >> lossy channel between two or more remote sites. >> >> o Protecting a Single Flow vs. Several Flows Globally: The FEC >> Framework can be used to protect a single flow, or several flows >> globally. >> >> 10.2. Operational and Management Recommendations >> >> Overall, from the discussion of Section 10.1, it is clear that the >> CDPs and FEC schemes compatible with the FEC Framework widely differ >> in their capabilities, application and deployment scenarios such that >> a common operation and management tool that works well for all of >> them does not exist. Thus, as a design choice, the FEC Framework >> does not dictate the use of any particular technology or protocol for >> transporting FEC data, managing the hosts, signaling the >> configuration information or encoding the configuration information. >> This provides flexibility and was one of the main goals of the FEC >> Framework. However, this section gives some recommendations. >> >> o A Single Small Generic Component within a Larger (and Often >> Legacy) Solution: It is anticipated that the FEC Framework will >> often be used to protect one or several RTP streams. Therefore, >> there are use cases that may take advantage of RTCP to collect >> feedback information, and one can take advantage of the associated >> tools to operate and manage the FEC Framework instance along with >> the associated FEC schemes. >> >> o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to- >> Many without Feedback Scenarios: With use cases that are one-way, >> the FEC Framework sender does not have any way to gather feedback >> from receivers. With use cases that are bidirectional, the FEC >> Framework sender can collect detailed feedback (e.g., in case of a >> one-to-one scenario) or at least occasional feedback (e.g., in >> case of a multicast, one-to-many scenario). All these >> applications have naturally different operational and management >> aspects. If any, they also have different requirements or >> features for collecting feedback, processing it and acting on it. >> The data structures for carrying the feedback also vary. >> >> o Non-FEC Framework Capable Receivers: Section 5.3 gives >> recommendations on how to provide backward compatibility in >> presence of receivers that cannot support the FEC scheme being >> used, or the FEC Framework itself: basically the use of Explicit >> Source FEC Payload ID is banned. Additionally, a non-FEC >> Framework capable receiver MUST also have a means not to receive >> the repair packets that it will not be able to decode in the first >> place or a means to identify and discard them appropriately upon >> receiving them. This can be achieved by sending repair packets on >> a different transport-layer flow. In case of an RTP source flow, >> this can also be achieved by using an RTP framing for FEC repair >> packets with a different payload type. Both source and repair >> packets can then be sent on the same transport-layer flow. It is >> the responsibility of the sender to select the appropriate >> mechanism when needed. >> >> o Congestion Control Considerations: See Section 8 for a discussion >> on whether congestion control is needed or not, and its >> relationships with the FEC Framework. >> >> o Within End-Systems vs. within Middleboxes: When the FEC Framework >> is used within middleboxes, it is RECOMMENDED that the paths >> between the hosts where the sending applications run and the >> middlebox that performs FEC encoding be as reliable as possible, >> since these paths are not protected against erasures by default. >> Similarly, it is RECOMMENDED that the paths between the >> middleboxes that perform FEC decoding and the end-systems where >> the receiving applications operate, in situations where this is a >> different host, be as reliable as possible since these paths are >> not protected against losses by default. >> >> The recommendation for the sending side is particularly important >> with FEC schemes that do not modify the ADU for backward >> compatibility purposes (i.e. do not use any Explicit Source FEC >> Payload ID) and rely for instance on the RTP sequence number field >> to identify FEC source packets within their source block. In this >> case, a loss on this path directly leads to a gap in the RTP >> sequence number space seen by the FECFRAME instance. This MUST be >> considered during source block creation by the FEC scheme. With >> FEC schemes that indicate in the Repair FEC Payload ID, for each >> source block, the base RTP sequence number and number of >> consecutive RTP packets that belong to this source block, an ADU >> loss requires to switch to a new source block. This SHOULD be >> discussed in the FEC scheme when there is a chance of losing a >> packet. >> >> o Protecting a Single Flow vs. Several Flows Globally: In the >> general case, the various ADU flows that are globally protected >> can have different features, and in particular different real-time >> requirements (in case of real-time flows). The process of >> globally protecting these flows SHOULD take into account the >> requirements of each individual flow. In particular, it would be >> counter-productive to add repair traffic to a real-time flow for >> which the FEC decoding delay at a receiver makes decoded ADUs for >> this flow useless because they do not satisfy the associated real- >> time constraints. From a practical point of view, this means that >> the source block creation process at the sending FEC Framework >> instance, SHOULD consider the most stringent real-time >> requirements of the ADU flows being globally protected. >> >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From luby@qualcomm.com Fri Feb 11 13:44:37 2011 Return-Path: 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 BCC353A69F5 for ; Fri, 11 Feb 2011 13:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 yhYs5DzhSfiX for ; Fri, 11 Feb 2011 13:44:35 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B7BB03A69DA for ; Fri, 11 Feb 2011 13:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1297460691; x=1328996691; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Vi ncent=20Roca=20|CC:=20"Ali=20C .=20Begen=20(abegen)"=20,=20"fecframe@i etf.org"=0D=0A=09,=20"dromasca@avaya.c om"=20,=20Sean=20Turner=0D=0A=09,=20Russ=20Housley=20 |Date:=20Fri,=2011=20Feb=202011=2013:44:46=20-0800 |Subject:=20Re:=20[Fecframe]=20Ops/Management=20Cons.=20t ext=20for=20fecframe|Thread-Topic:=20[Fecframe]=20Ops/Man agement=20Cons.=20text=20for=20fecframe|Thread-Index:=20A cvKNGo7gcg8S2dZTmOazXHIt0xnogAAHwBm|Message-ID:=20|In-Reply-To:=20<4D553D18.20501 06@inrialpes.fr>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|user-agent:=20Microsoft-Entourage/ 13.8.0.101117|acceptlanguage:=20en-US|Content-Type:=20tex t/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=eyaTefzCAudfHukUkbzkRta2RM6DJKKA0mx212fEOJU=; b=LLb8Hq0+HQ76n+/7sMT6roGOr4je3DokXSce4UAPAORu2EI2tDejzn6h 2bvnQvmn/mcF1aokfht90TwvHDNDJNrTv4EGZWm335y2A5aRm5X+v3sUx ra1YVINldJPRIfZtX5ItPC+iuRfNdrlZIwAYBiMqQcCKkloXQsAbPNHrO Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6254"; a="73905376" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 11 Feb 2011 13:44:51 -0800 X-IronPort-AV: E=Sophos;i="4.60,455,1291622400"; d="scan'208";a="115514455" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 11 Feb 2011 13:44:51 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhc07.na.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 11 Feb 2011 13:44:51 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Fri, 11 Feb 2011 13:44:50 -0800 From: "Luby, Michael" To: Vincent Roca Date: Fri, 11 Feb 2011 13:44:46 -0800 Thread-Topic: [Fecframe] Ops/Management Cons. text for fecframe Thread-Index: AcvKNGo7gcg8S2dZTmOazXHIt0xnogAAHwBm Message-ID: In-Reply-To: <4D553D18.2050106@inrialpes.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dromasca@avaya.com" , Sean Turner , Russ Housley , "fecframe@ietf.org" Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe 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: , X-List-Received-Date: Fri, 11 Feb 2011 21:44:37 -0000 Looks good. On 2/11/11 5:43 AM, "Vincent Roca" wrote: > Hello Mike, >=20 > That's an important operational aspect that we omitted, > I agree. I suggest to add the following text as you suggest: >=20 > --- > ADU Flow Bundle Definition and Flow Delivery Considerations: >=20 > By design a repair flow may enable a receiver to recover the > ADU flow(s) that it protects even if none of the associated FEC > source packet is received. Therefore, when defining the bundle > of ADU flows that are globally protected and when defining > which receiver receives which flow, the repair flow(s) SHOULD > only be received by receivers that are authorized to receive all > the associated ADU flows. See Section 9.4 for additional > recommendations for situations where a strict access control > to ADU flows is needed. >=20 > Additionally when multiple ADU flows are globally protected, > a receiver who wants to benefit from FECFRAME loss protection > SHOULD receive all the ADU flows of the bundle. Otherwise the > missing FEC source packets would be considered as lost which > may significantly reduce the efficiency of the FEC Scheme. > --- >=20 > Cheers, >=20 > Vincent >=20 >=20 >=20 >=20 > On 11/02/11 00:57, Luby, Michael wrote: >> This looks good Ali. One thing to perhaps add at the end of Section 10.= 2 is >> that if multiple "source flows" are protected by a single FEC repair str= eam >> (generated from the bundle of the source flows) then it should be the ca= se >> that all of these flows are received by receivers who expect to receive = and >> use the FEC repair stream generated from them (as otherwise the source f= lows >> that are not received will be considered as loss by the receiver, and al= so >> it might allow the receiver to recover flows that are not meant for it t= o >> receive, a security concern). >>=20 >> I guess perhaps it is good to add a general security statement that says >> that it is important to only allow FEC repair be received by receivers f= or >> which all of the original source from which the FEC repair is generated = can >> be received by those receivers. (Otherwise, the receivers might be able= to >> recover source flows using FEC repair that they are not supposed to >> receive.) >>=20 >>=20 >> On 2/10/11 12:51 PM, "Ali C. Begen (abegen)" wrote: >>=20 >>> We have not seen any email from the DISCUSS holders (except David) rega= rding >>> the framework draft in the mailing list (I did not see any private emai= l, >>> either and for some reason the system is not including me in the emails= from >>> IESG). We need to publish this specification as it is holding several o= ther >>> documents, and even the WG itself (Clearly, many of us are eager to clo= se >>> the >>> WG). >>>=20 >>> Here is a summary of where we stand now: >>>=20 >>> The DISCUSS from Russ H. is about some inconsistency in section 5, whic= h was >>> fixed 2 versions ago. >>>=20 >>> The DISCUSS Sean T. is about the security related issues, which were >>> addressed >>> in the last revision. >>>=20 >>> Russ, Sean, if you still have issues with the revised text, please rais= e >>> them. >>>=20 >>> The DISCUSS from Dan R. and David H. are related to ops/management issu= es. >>> We >>> had a lot discussion on this in the mailing list, and the text below >>> attempts >>> to reflect the view of the WG on this subject. >>>=20 >>> We would like to get your (WG individuals but in particular the DISCUSS >>> holders) comments on this text. The sooner the better as we would like = to >>> close this issue before the next meeting and ship the draft to the edit= or. >>>=20 >>> Approvals/objections are welcome as usual. >>>=20 >>> -acbegen >>>=20 >>>=20 >>> 10. Operations and Management Considerations >>>=20 >>> The question of operating and managing the FEC Framework and the >>> associated FEC scheme(s) is of high practical importance. The goal= s >>> of this section are to discuss the general requirements, aspects >>> related to a specific deployment and solutions whenever possible. >>>=20 >>> In particular, this section discusses the questions of >>> interoperability across vendors/use cases and whether defining >>> mandatory to implement (but not mandatory to use) solutions is >>> beneficial. >>>=20 >>> 10.1. What are the Key Aspects to Consider? >>>=20 >>> Several aspects need to be considered since they will directly impa= ct >>> the way the FEC Framework and the associated FEC schemes can be >>> operated and managed. >>>=20 >>> This section lists them as follows: >>>=20 >>> o A Single Small Generic Component within a Larger (and Often >>> Legacy) Solution: The FEC Framework is one component within a >>> larger solution which includes both one or several upper-layer >>> applications (that generate one or several ADU flows) and an >>> underlying protocol stack. A key design principle is that the F= EC >>> Framework should be able to work without making any assumption >>> with respect to either the upper-layer application(s) or the >>> underlying protocol stack, even if there are special cases where >>> assumptions are made. >>>=20 >>> o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-t= o- >>> Many without Feedback Scenarios: The FEC Framework can be used i= n >>> use cases that completely differ from one another. Some use cas= es >>> are one-way (e.g., in broadcast networks), with either a one-to- >>> one, one-to-many or many-to-many transmission model, and the >>> receiver(s) cannot send any feedback to the sender(s). Other us= e >>> cases follow a bidirectional one-to-one, one-to-many, or many-to= - >>> many scenario, and the receiver(s) can send feedback to the >>> sender(s). >>>=20 >>> o Non-FEC Framework Capable Receivers: With the one-to-many and >>> many-to-many use cases, the receiver population might have >>> different capabilities with respect to the FEC Framework itself >>> and the supported FEC schemes. Some receivers might not be >>> capable of decoding the repair packets belonging to a particular >>> FEC scheme, while some other receivers might not be supporting t= he >>> FEC Framework at all. >>>=20 >>> o Internet vs. non-Internet Networks: The FEC Framework can be >>> useful in many use cases that use a transport network that is no= t >>> the public Internet (e.g., with IPTV or Mobile TV). In such >>> networks, the operational and management considerations can be >>> achieved through an open or proprietary solution, which is >>> specified outside of the IETF. >>>=20 >>> o Congestion Control Considerations: See Section 8 for a discussio= n >>> on whether congestion control is needed or not, and its >>> relationships with the FEC Framework. >>>=20 >>> o Within End-Systems vs. within Middleboxes: The FEC Framework can >>> be used within end-systems, very close to the upper-layer >>> application, or within dedicated middleboxes, for instance when = it >>> is desired to protect one or several flows while they cross a >>> lossy channel between two or more remote sites. >>>=20 >>> o Protecting a Single Flow vs. Several Flows Globally: The FEC >>> Framework can be used to protect a single flow, or several flows >>> globally. >>>=20 >>> 10.2. Operational and Management Recommendations >>>=20 >>> Overall, from the discussion of Section 10.1, it is clear that the >>> CDPs and FEC schemes compatible with the FEC Framework widely diffe= r >>> in their capabilities, application and deployment scenarios such th= at >>> a common operation and management tool that works well for all of >>> them does not exist. Thus, as a design choice, the FEC Framework >>> does not dictate the use of any particular technology or protocol f= or >>> transporting FEC data, managing the hosts, signaling the >>> configuration information or encoding the configuration information= . >>> This provides flexibility and was one of the main goals of the FEC >>> Framework. However, this section gives some recommendations. >>>=20 >>> o A Single Small Generic Component within a Larger (and Often >>> Legacy) Solution: It is anticipated that the FEC Framework will >>> often be used to protect one or several RTP streams. Therefore, >>> there are use cases that may take advantage of RTCP to collect >>> feedback information, and one can take advantage of the associat= ed >>> tools to operate and manage the FEC Framework instance along wit= h >>> the associated FEC schemes. >>>=20 >>> o One-to-One with Feedback vs. One-to-Many with Feedback vs. One-t= o- >>> Many without Feedback Scenarios: With use cases that are one-way= , >>> the FEC Framework sender does not have any way to gather feedbac= k >>> from receivers. With use cases that are bidirectional, the FEC >>> Framework sender can collect detailed feedback (e.g., in case of= a >>> one-to-one scenario) or at least occasional feedback (e.g., in >>> case of a multicast, one-to-many scenario). All these >>> applications have naturally different operational and management >>> aspects. If any, they also have different requirements or >>> features for collecting feedback, processing it and acting on it= . >>> The data structures for carrying the feedback also vary. >>>=20 >>> o Non-FEC Framework Capable Receivers: Section 5.3 gives >>> recommendations on how to provide backward compatibility in >>> presence of receivers that cannot support the FEC scheme being >>> used, or the FEC Framework itself: basically the use of Explicit >>> Source FEC Payload ID is banned. Additionally, a non-FEC >>> Framework capable receiver MUST also have a means not to receive >>> the repair packets that it will not be able to decode in the fir= st >>> place or a means to identify and discard them appropriately upon >>> receiving them. This can be achieved by sending repair packets = on >>> a different transport-layer flow. In case of an RTP source flow= , >>> this can also be achieved by using an RTP framing for FEC repair >>> packets with a different payload type. Both source and repair >>> packets can then be sent on the same transport-layer flow. It i= s >>> the responsibility of the sender to select the appropriate >>> mechanism when needed. >>>=20 >>> o Congestion Control Considerations: See Section 8 for a discussio= n >>> on whether congestion control is needed or not, and its >>> relationships with the FEC Framework. >>>=20 >>> o Within End-Systems vs. within Middleboxes: When the FEC Framewor= k >>> is used within middleboxes, it is RECOMMENDED that the paths >>> between the hosts where the sending applications run and the >>> middlebox that performs FEC encoding be as reliable as possible, >>> since these paths are not protected against erasures by default. >>> Similarly, it is RECOMMENDED that the paths between the >>> middleboxes that perform FEC decoding and the end-systems where >>> the receiving applications operate, in situations where this is = a >>> different host, be as reliable as possible since these paths are >>> not protected against losses by default. >>>=20 >>> The recommendation for the sending side is particularly importan= t >>> with FEC schemes that do not modify the ADU for backward >>> compatibility purposes (i.e. do not use any Explicit Source FEC >>> Payload ID) and rely for instance on the RTP sequence number fie= ld >>> to identify FEC source packets within their source block. In th= is >>> case, a loss on this path directly leads to a gap in the RTP >>> sequence number space seen by the FECFRAME instance. This MUST = be >>> considered during source block creation by the FEC scheme. With >>> FEC schemes that indicate in the Repair FEC Payload ID, for each >>> source block, the base RTP sequence number and number of >>> consecutive RTP packets that belong to this source block, an ADU >>> loss requires to switch to a new source block. This SHOULD be >>> discussed in the FEC scheme when there is a chance of losing a >>> packet. >>>=20 >>> o Protecting a Single Flow vs. Several Flows Globally: In the >>> general case, the various ADU flows that are globally protected >>> can have different features, and in particular different real-ti= me >>> requirements (in case of real-time flows). The process of >>> globally protecting these flows SHOULD take into account the >>> requirements of each individual flow. In particular, it would b= e >>> counter-productive to add repair traffic to a real-time flow for >>> which the FEC decoding delay at a receiver makes decoded ADUs fo= r >>> this flow useless because they do not satisfy the associated rea= l- >>> time constraints. From a practical point of view, this means th= at >>> the source block creation process at the sending FEC Framework >>> instance, SHOULD consider the most stringent real-time >>> requirements of the ADU flows being globally protected. >>>=20 >>>=20 >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe From stewe@stewe.org Sun Feb 13 10:40:59 2011 Return-Path: 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 6956F3A6A1C; Sun, 13 Feb 2011 10:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 Nz0VYpBVapwi; Sun, 13 Feb 2011 10:40:58 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id DE1BE3A6A00; Sun, 13 Feb 2011 10:40:57 -0800 (PST) Received: from [192.168.1.106] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4221-1743317 for multiple; Sun, 13 Feb 2011 19:41:17 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Sun, 13 Feb 2011 10:41:10 +0100 From: Stephan Wenger To: IETF AVT WG , , Message-ID: Thread-Topic: Incoming liaison from MPEG Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3380438477_1401406" X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Subject: [Fecframe] Incoming liaison from MPEG 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: , X-List-Received-Date: Sun, 13 Feb 2011 18:40:59 -0000 > 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_3380438477_1401406 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, We have received a liaison statement from MPEG. They inform us of their progress at their last meeting in Korea. Their streaming over HTTP technology (known as DASH) is now in Draft International Standard (DIS) state, and support for DASH has also been included in a Draft Amendment to their MPEG-4 file format specification. With respect to the latter, the AVT folks may find the informal description of RTP's synchronization mechanisms in Annex H particularly interesting. I glanced over it and found it consistent with RTP and its common use, but perhaps someone else wants to check as well? No actions are required by the IETF, but they welcome comments and participation. The statement should be available in the official IETF tracker (https://datatracker.ietf.org/liaison/) shortly; until then, you can email me for a copy. Regards, Stephan --B_3380438477_1401406 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,
We have re= ceived a liaison statement from MPEG.  They inform us of their progress= at their last meeting in Korea.  Their streaming over HTTP technology = (known as DASH) is now in Draft International Standard (DIS) state, and supp= ort for DASH has also been included in a Draft Amendment to their MPEG-4 fil= e format specification.  With respect to the latter, the AVT folks may = find the informal description of RTP's synchronization mechanisms in Annex H= particularly interesting.  I glanced over it and found it consistent w= ith RTP and its common use, but perhaps someone else wants to check as well?=
No actions are required by the IETF, but they welcome comments an= d participation.
The statement should be available in the official= IETF tracker (https://datatr= acker.ietf.org/liaison/) shortly; until then, you can email me for a cop= y.
Regards,
Stephan
  
<= /html> --B_3380438477_1401406-- From abegen@cisco.com Sun Feb 13 14:04:23 2011 Return-Path: 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 EE4B93A6C2E for ; Sun, 13 Feb 2011 14:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 73jnRsHWX87L for ; Sun, 13 Feb 2011 14:04:22 -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 6FEB43A6A31 for ; Sun, 13 Feb 2011 14:04:22 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4BAB/kV02rR7H+/2dsb2JhbACXKI5ac54dmiaCfROCTgSFBIoz X-IronPort-AV: E=Sophos;i="4.60,466,1291593600"; d="scan'208";a="661999034" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 13 Feb 2011 22:04:43 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1DM4h6q017266; Sun, 13 Feb 2011 22:04:43 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.4675); Sun, 13 Feb 2011 14:04:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Feb 2011 14:04:37 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E4C8175@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ops/Management Cons. text for fecframe Thread-Index: AcvJX4LOUPpFWWZQSDGUx+2+eq2IFgCC+c2gABeKLXA= References: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7BA9@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 13 Feb 2011 22:04:43.0395 (UTC) FILETIME=[04C39530:01CBCBCA] Cc: Sean Turner , Russ Housley Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe 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: , X-List-Received-Date: Sun, 13 Feb 2011 22:04:24 -0000 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Sunday, February 13, 2011 5:58 AM > To: Ali C. Begen (abegen); fecframe@ietf.org > Cc: Russ Housley; Sean Turner; ietfdbh@comcast.net > Subject: RE: Ops/Management Cons. text for fecframe >=20 > Hi, >=20 > Thank you for addressing the issue. See comments in-line. >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Thursday, February 10, 2011 10:51 PM > > To: fecframe@ietf.org > > Cc: Russ Housley; Sean Turner; ietfdbh@comcast.net; > > Romascanu, Dan (Dan) > > Subject: Ops/Management Cons. text for fecframe > > > > We have not seen any email from the DISCUSS holders (except > > David) regarding the framework draft in the mailing list (I > > did not see any private email, either and for some reason the > > system is not including me in the emails from IESG). We need > > to publish this specification as it is holding several other > > documents, and even the WG itself (Clearly, many of us are > > eager to close the WG). > > > > Here is a summary of where we stand now: > > > > The DISCUSS from Russ H. is about some inconsistency in > > section 5, which was fixed 2 versions ago. > > > > The DISCUSS Sean T. is about the security related issues, > > which were addressed in the last revision. > > > > Russ, Sean, if you still have issues with the revised text, > > please raise them. > > > > The DISCUSS from Dan R. and David H. are related to > > ops/management issues. We had a lot discussion on this in the > > mailing list, and the text below attempts to reflect the view > > of the WG on this subject. > > > > We would like to get your (WG individuals but in particular > > the DISCUSS holders) comments on this text. The sooner the > > better as we would like to close this issue before the next > > meeting and ship the draft to the editor. > > > > Approvals/objections are welcome as usual. > > > > -acbegen > > > > > > 10. Operations and Management Considerations > > > > The question of operating and managing the FEC Framework and the > > associated FEC scheme(s) is of high practical importance. > > The goals > > of this section are to discuss the general requirements, aspects > > related to a specific deployment and solutions whenever possible. > > > > In particular, this section discusses the questions of > > interoperability across vendors/use cases and whether defining > > mandatory to implement (but not mandatory to use) solutions is > > beneficial. > > > > 10.1. What are the Key Aspects to Consider? > > > > Several aspects need to be considered since they will > > directly impact > > the way the FEC Framework and the associated FEC schemes can be > > operated and managed. > > > > This section lists them as follows: > > > > o A Single Small Generic Component within a Larger (and Often > > Legacy) Solution: The FEC Framework is one component within a > > larger solution which includes both one or several upper-layer > > applications (that generate one or several ADU flows) and an > > underlying protocol stack. A key design principle is > > that the FEC > > Framework should be able to work without making any assumption > > with respect to either the upper-layer application(s) or the > > underlying protocol stack, even if there are special cases = where > > assumptions are made. > > > > o One-to-One with Feedback vs. One-to-Many with Feedback > > vs. One-to- > > Many without Feedback Scenarios: The FEC Framework can > > be used in > > use cases that completely differ from one another. > > Some use cases > > are one-way (e.g., in broadcast networks), with either a = one-to- > > one, one-to-many or many-to-many transmission model, and the > > receiver(s) cannot send any feedback to the sender(s). > > Other use > > cases follow a bidirectional one-to-one, one-to-many, > > or many-to- > > many scenario, and the receiver(s) can send feedback to the > > sender(s). > > > > o Non-FEC Framework Capable Receivers: With the one-to-many and > > many-to-many use cases, the receiver population might have > > different capabilities with respect to the FEC Framework = itself > > and the supported FEC schemes. Some receivers might not be > > capable of decoding the repair packets belonging to a = particular > > FEC scheme, while some other receivers might not be > > supporting the > > FEC Framework at all. > > > > o Internet vs. non-Internet Networks: The FEC Framework can be > > useful in many use cases that use a transport network > > that is not > > the public Internet (e.g., with IPTV or Mobile TV). In such > > networks, the operational and management considerations can be > > achieved through an open or proprietary solution, which is > > specified outside of the IETF. > > > > o Congestion Control Considerations: See Section 8 for a > > discussion > > on whether congestion control is needed or not, and its > > relationships with the FEC Framework. > > > > o Within End-Systems vs. within Middleboxes: The FEC Framework = can > > be used within end-systems, very close to the upper-layer > > application, or within dedicated middleboxes, for > > instance when it > > is desired to protect one or several flows while they cross a > > lossy channel between two or more remote sites. > > > > o Protecting a Single Flow vs. Several Flows Globally: The FEC > > Framework can be used to protect a single flow, or several = flows > > globally. > > > > 10.2. Operational and Management Recommendations > > > > Overall, from the discussion of Section 10.1, it is clear that = the > > CDPs and FEC schemes compatible with the FEC Framework > > widely differ > > in their capabilities, application and deployment > > scenarios such that > > a common operation and management tool that works well for all of > > them does not exist. >=20 > I am not sure that we are talking here about 'tools' or rather methods > and/or protocols. Also 'does not exist' is not the question - the > question is whether managing CDPs and FEC schemes compatible with the > FEC framework is too complex a task to be solved by one standard = method > or protocol. I suggest adjusting the text to make this clear. Your proposed wording is more accurate. Thanks. > > Thus, as a design choice, the FEC Framework > > does not dictate the use of any particular technology or > > protocol for > > transporting FEC data, managing the hosts, signaling the > > configuration information or encoding the configuration > > information. > > This provides flexibility and was one of the main goals of the = FEC > > Framework. However, this section gives some recommendations. > > > > o A Single Small Generic Component within a Larger (and Often > > Legacy) Solution: It is anticipated that the FEC Framework = will > > often be used to protect one or several RTP streams. = Therefore, > > there are use cases that may take advantage of RTCP to collect > > feedback information, and one can take advantage of the > > associated > > tools to operate and manage the FEC Framework instance > > along with > > the associated FEC schemes. >=20 > By 'associated tools' you mean here tools using RTCP? I will change it to "tools using (or used by) RTCP". =20 > > > > o One-to-One with Feedback vs. One-to-Many with Feedback > > vs. One-to- > > Many without Feedback Scenarios: With use cases that > > are one-way, > > the FEC Framework sender does not have any way to > > gather feedback > > from receivers. With use cases that are bidirectional, the = FEC > > Framework sender can collect detailed feedback (e.g., > > in case of a > > one-to-one scenario) or at least occasional feedback (e.g., in > > case of a multicast, one-to-many scenario). All these > > applications have naturally different operational and = management > > aspects. If any, they also have different requirements or > > features for collecting feedback, processing it and > > acting on it. > > The data structures for carrying the feedback also vary. > > > > o Non-FEC Framework Capable Receivers: Section 5.3 gives > > recommendations on how to provide backward compatibility in > > presence of receivers that cannot support the FEC scheme being > > used, or the FEC Framework itself: basically the use of = Explicit > > Source FEC Payload ID is banned. Additionally, a non-FEC > > Framework capable receiver MUST also have a means not to = receive > > the repair packets that it will not be able to decode > > in the first > > place or a means to identify and discard them appropriately = upon > > receiving them. This can be achieved by sending repair > > packets on > > a different transport-layer flow. In case of an RTP > > source flow, > > this can also be achieved by using an RTP framing for FEC = repair > > packets with a different payload type. Both source and repair > > packets can then be sent on the same transport-layer > > flow. It is > > the responsibility of the sender to select the appropriate > > mechanism when needed. > > > > o Congestion Control Considerations: See Section 8 for a > > discussion > > on whether congestion control is needed or not, and its > > relationships with the FEC Framework. > > >=20 > I am not sure that Congestion Control belongs here or rather in > Transport Considerations. Well, we can remove it as we already detailed congestion control issues = earlier in the document. -acbegen =20 > > o Within End-Systems vs. within Middleboxes: When the FEC > > Framework > > is used within middleboxes, it is RECOMMENDED that the paths > > between the hosts where the sending applications run and the > > middlebox that performs FEC encoding be as reliable as = possible, > > since these paths are not protected against erasures by = default. > > Similarly, it is RECOMMENDED that the paths between the > > middleboxes that perform FEC decoding and the end-systems = where > > the receiving applications operate, in situations where > > this is a > > different host, be as reliable as possible since these paths = are > > not protected against losses by default. > > > > The recommendation for the sending side is particularly > > important > > with FEC schemes that do not modify the ADU for backward > > compatibility purposes (i.e. do not use any Explicit Source = FEC > > Payload ID) and rely for instance on the RTP sequence > > number field > > to identify FEC source packets within their source > > block. In this > > case, a loss on this path directly leads to a gap in the RTP > > sequence number space seen by the FECFRAME instance. > > This MUST be > > considered during source block creation by the FEC scheme. = With > > FEC schemes that indicate in the Repair FEC Payload ID, for = each > > source block, the base RTP sequence number and number of > > consecutive RTP packets that belong to this source block, an = ADU > > loss requires to switch to a new source block. This SHOULD be > > discussed in the FEC scheme when there is a chance of losing a > > packet. > > > > o Protecting a Single Flow vs. Several Flows Globally: In the > > general case, the various ADU flows that are globally = protected > > can have different features, and in particular > > different real-time > > requirements (in case of real-time flows). The process of > > globally protecting these flows SHOULD take into account the > > requirements of each individual flow. In particular, > > it would be > > counter-productive to add repair traffic to a real-time flow = for > > which the FEC decoding delay at a receiver makes > > decoded ADUs for > > this flow useless because they do not satisfy the > > associated real- > > time constraints. From a practical point of view, this > > means that > > the source block creation process at the sending FEC Framework > > instance, SHOULD consider the most stringent real-time > > requirements of the ADU flows being globally protected. > > > > > > From abegen@cisco.com Mon Feb 14 03:34:59 2011 Return-Path: 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 02BEB3A6CC2 for ; Mon, 14 Feb 2011 03:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 sR+ND-Wwp91g for ; Mon, 14 Feb 2011 03:34:57 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 32ED33A6CC1 for ; Mon, 14 Feb 2011 03:34:57 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG6iWE2rRN+J/2dsb2JhbACmBnOedZpZhV4EhQSKMw X-IronPort-AV: E=Sophos;i="4.60,468,1291593600"; d="scan'208";a="263110946" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2011 11:35:19 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1EBZJTq010762; Mon, 14 Feb 2011 11:35:19 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.4675); Mon, 14 Feb 2011 03:35:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2011 03:35:16 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E4C81F5@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ops/Management Cons. text for fecframe Thread-Index: AcvJX4LOUPpFWWZQSDGUx+2+eq2IFgCC+c2gABeKLXAAFFiU0AAICyEg References: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7BA9@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540E4C8175@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 14 Feb 2011 11:35:19.0588 (UTC) FILETIME=[4231AE40:01CBCC3B] Cc: Sean Turner , Russ Housley Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe 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: , X-List-Received-Date: Mon, 14 Feb 2011 11:34:59 -0000 > I am OK with your proposed changes. Thanks. David, Should we submit a revision with these changes (and addressing the = comments from the list)? -acbegen =20 > Regards, >=20 > Dan >=20 From gjshep@gmail.com Tue Feb 15 07:58:42 2011 Return-Path: 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 228863A6AB2 for ; Tue, 15 Feb 2011 07:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 t2bd8vcSNM3y for ; Tue, 15 Feb 2011 07:58:41 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C8DE63A6A9E for ; Tue, 15 Feb 2011 07:58:40 -0800 (PST) Received: by fxm9 with SMTP id 9so416583fxm.31 for ; Tue, 15 Feb 2011 07:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=FG/pFcH2ihC8CrUaErdlRacQkL/FIS2Q6o/dJhvCofM=; b=djHUehtJlBn1JHSzRoQbTb1TnSzc7x23O9voprUSVSXR77QA2E0O7f1kWCRog/Sg2s yTDbw+RKmf8krAt+UtUxZrT5kzw1wPowKg4e5kQzZZvgUt1BOlUBmYaHGTG1CPS0T5dw umdkk7nOvdHDIi9f6ZwEScB6JFTuh5TqaSxds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=YrIj7FJRIFWlPQs1lsp9P9MKt1UbXLRK81cWTUM/7ZF6vGRjJAebVlNp4Ug+7z+301 T2no+3JAZTPR+wVIoKMKcNwUIfH6SHxDKpemaY4mnj5ayHQAgPlw+VEl+zaO3G2XiXo+ SDDeXK6FgDb+hhsSPEKSp9RdhJ8QbUCP49sXA= MIME-Version: 1.0 Received: by 10.223.71.199 with SMTP id i7mr2212799faj.57.1297785546087; Tue, 15 Feb 2011 07:59:06 -0800 (PST) Received: by 10.223.27.198 with HTTP; Tue, 15 Feb 2011 07:59:06 -0800 (PST) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E4C81F5@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7BA9@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540E4C8175@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540E4C81F5@xmb-sjc-215.amer.cisco.com> Date: Tue, 15 Feb 2011 07:59:06 -0800 Message-ID: From: Greg Shepherd To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Romascanu, Dan \(Dan\)" , Sean Turner , Russ Housley , fecframe@ietf.org Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 15:58:42 -0000 Ali, Yes, please submit a revision with these changes. Thanks, Greg On Mon, Feb 14, 2011 at 3:35 AM, Ali C. Begen (abegen) wrote: > >> I am OK with your proposed changes. > > Thanks. > > David, > > Should we submit a revision with these changes (and addressing the comments from the list)? > > -acbegen > >> Regards, >> >> Dan >> > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From abegen@cisco.com Tue Feb 15 14:08:51 2011 Return-Path: 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 C95B63A6A6F for ; Tue, 15 Feb 2011 14:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 9bLPldgfEk2w for ; Tue, 15 Feb 2011 14:08:51 -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 19E003A684E for ; Tue, 15 Feb 2011 14:08:51 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIBAMOIWk2rR7Ht/2dsb2JhbACXBD+OHHOgXJtihV4EhQWKOIMG X-IronPort-AV: E=Sophos;i="4.60,476,1291593600"; d="scan'208";a="330331763" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 15 Feb 2011 22:09:17 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1FM9HwB028059; Tue, 15 Feb 2011 22:09:17 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.4675); Tue, 15 Feb 2011 14:09:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2011 14:08:51 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E57B2CC@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Ops/Management Cons. text for fecframe Thread-Index: AcvNKUhHQ9H76Km9RW2smw7HxNVf7gAM1hLA References: <04CAD96D4C5A3D48B1919248A8FE0D540E4C7BA9@xmb-sjc-215.amer.cisco.com><04CAD96D4C5A3D48B1919248A8FE0D540E4C8175@xmb-sjc-215.amer.cisco.com><04CAD96D4C5A3D48B1919248A8FE0D540E4C81F5@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 15 Feb 2011 22:09:17.0545 (UTC) FILETIME=[FCFF0D90:01CBCD5C] Cc: "Romascanu, Dan \(Dan\)" , Sean Turner , Russ Housley , fecframe@ietf.org Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe 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: , X-List-Received-Date: Tue, 15 Feb 2011 22:08:51 -0000 Revision has been submitted.=20 Dan, David, Russ and Sean, Please let us know if this revision addressed your concerns and = DISCUSSes. https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/=20 Thanks. -acbegen > -----Original Message----- > From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Tuesday, February 15, 2011 10:59 AM > To: Ali C. Begen (abegen) > Cc: Romascanu, Dan (Dan); fecframe@ietf.org; Sean Turner; Russ Housley > Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe >=20 > Ali, >=20 > Yes, please submit a revision with these changes. >=20 > Thanks, > Greg >=20 > On Mon, Feb 14, 2011 at 3:35 AM, Ali C. Begen (abegen) = wrote: > > > >> I am OK with your proposed changes. > > > > Thanks. > > > > David, > > > > Should we submit a revision with these changes (and addressing the = comments from the list)? > > > > -acbegen > > > >> Regards, > >> > >> Dan > >> > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > From Internet-Drafts@ietf.org Tue Feb 15 14:15:03 2011 Return-Path: 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 BB0123A6CD9; Tue, 15 Feb 2011 14:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 VMEGV51piBt4; Tue, 15 Feb 2011 14:15:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05CAB3A6AFF; Tue, 15 Feb 2011 14:15:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110215221503.3133.23727.idtracker@localhost> Date: Tue, 15 Feb 2011 14:15:03 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-framework-13.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: , X-List-Received-Date: Tue, 15 Feb 2011 22:15:03 -0000 --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 : Forward Error Correction (FEC) Framework Author(s) : M. Watson, et al. Filename : draft-ietf-fecframe-framework-13.txt Pages : 47 Date : 2011-02-15 This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC scheme, and FEC schemes can be defined which are not specific to a particular Content Delivery Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-framework-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-fecframe-framework-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-15140550.I-D@ietf.org> --NextPart-- From luby@qualcomm.com Tue Feb 15 17:40:02 2011 Return-Path: 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 9D9173A684E for ; Tue, 15 Feb 2011 17:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 NkBC-QPyW5QH for ; Tue, 15 Feb 2011 17:40:00 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D12863A6B6F for ; Tue, 15 Feb 2011 17:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1297820428; x=1329356428; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"A li=20C.=20Begen=20(abegen)"=20,=20Greg =20Shepherd=0D=0A=09|CC:=20"Romascanu, =20Dan=20(Dan)"=20,=20Sean=20Turner =0D=0A=09,=20Russ=20Housley=20,=20"fecframe@ietf.org"=0D=0A=09|Date:=20Tue,=2015=20Feb=202011=2017:40:23=20-0800 |Subject:=20Re:=20[Fecframe]=20Ops/Management=20Cons.=20t ext=20for=20fecframe|Thread-Topic:=20[Fecframe]=20Ops/Man agement=20Cons.=20text=20for=20fecframe|Thread-Index:=20A cvNKUhHQ9H76Km9RW2smw7HxNVf7gAM1hLAAAd2aLY=3D|Message-ID: =20|In-Reply-To:=20<04CA D96D4C5A3D48B1919248A8FE0D540E57B2CC@xmb-sjc-215.amer.cis co.com>|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mi crosoft-Entourage/13.8.0.101117|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=Yjz0cLK4IXmTbbocNLiKvVIENo5uBNwufwASysxEHak=; b=wLOAZ52SzT0azKK8tMmeJl1DqEwWPp1tp9N+mREa8yovLDrnwUV/1v10 Zb+ZL0HAgKVawuYe11KXfGwdkLsyPcqfWow9m5mLrhFkQ+jE9hLhJLIgD UUBCH8aZlS4hfeiisFb92kRqggl40YvQQB+oFGg9SVbPIx8jhIf7pRz4e w=; X-IronPort-AV: E=McAfee;i="5400,1158,6258"; a="74432139" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 15 Feb 2011 17:40:27 -0800 X-IronPort-AV: E=Sophos;i="4.60,474,1291622400"; d="scan'208";a="31137657" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 15 Feb 2011 17:40:27 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 15 Feb 2011 17:40:26 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Tue, 15 Feb 2011 17:40:27 -0800 From: "Luby, Michael" To: "Ali C. Begen (abegen)" , Greg Shepherd Date: Tue, 15 Feb 2011 17:40:23 -0800 Thread-Topic: [Fecframe] Ops/Management Cons. text for fecframe Thread-Index: AcvNKUhHQ9H76Km9RW2smw7HxNVf7gAM1hLAAAd2aLY= Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E57B2CC@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Romascanu, Dan \(Dan\)" , Sean Turner , Russ Housley , "fecframe@ietf.org" Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe 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: , X-List-Received-Date: Wed, 16 Feb 2011 01:40:02 -0000 Looks good. One thing that I still think worth adding is something about potential packet reordering, i.e., whereever loss is an issue it perhaps should be mentioned that packet reordering can also be an issue that needs to be considered addressed. This is all wrt the Management/Deployment section. On 2/15/11 2:08 PM, "Ali C. Begen (abegen)" wrote: > Revision has been submitted. >=20 > Dan, David, Russ and Sean, >=20 > Please let us know if this revision addressed your concerns and DISCUSSes= . > https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ >=20 > Thanks. > -acbegen >=20 >> -----Original Message----- >> From: Greg Shepherd [mailto:gjshep@gmail.com] >> Sent: Tuesday, February 15, 2011 10:59 AM >> To: Ali C. Begen (abegen) >> Cc: Romascanu, Dan (Dan); fecframe@ietf.org; Sean Turner; Russ Housley >> Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe >>=20 >> Ali, >>=20 >> Yes, please submit a revision with these changes. >>=20 >> Thanks, >> Greg >>=20 >> On Mon, Feb 14, 2011 at 3:35 AM, Ali C. Begen (abegen) >> wrote: >>>=20 >>>> I am OK with your proposed changes. >>>=20 >>> Thanks. >>>=20 >>> David, >>>=20 >>> Should we submit a revision with these changes (and addressing the comm= ents >>> from the list)? >>>=20 >>> -acbegen >>>=20 >>>> Regards, >>>>=20 >>>> Dan >>>>=20 >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>>=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Wed Feb 16 18:26:24 2011 Return-Path: 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 A3D583A6E98 for ; Wed, 16 Feb 2011 18:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Vu48FlYv8SlK for ; Wed, 16 Feb 2011 18:26:23 -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 ABA613A6E97 for ; Wed, 16 Feb 2011 18:26:23 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigBAAcWXE2rR7Hu/2dsb2JhbACXSo5Jc6FMm1KCfYJhBIUJikI X-IronPort-AV: E=Sophos;i="4.60,483,1291593600"; d="scan'208";a="261272340" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 17 Feb 2011 02:26:53 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1H2QrXE000338; Thu, 17 Feb 2011 02:26:53 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.4675); Wed, 16 Feb 2011 18:26:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2011 18:26:43 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E57B925@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Ops/Management Cons. text for fecframe Thread-Index: AcvNKUhHQ9H76Km9RW2smw7HxNVf7gAM1hLAAAd2aLYAM9JicA== References: <04CAD96D4C5A3D48B1919248A8FE0D540E57B2CC@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Luby, Michael" , "Greg Shepherd" X-OriginalArrivalTime: 17 Feb 2011 02:26:53.0491 (UTC) FILETIME=[23DF0030:01CBCE4A] Cc: Sean Turner , Russ Housley , fecframe@ietf.org Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe 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: , X-List-Received-Date: Thu, 17 Feb 2011 02:26:24 -0000 OK, I got a revised text from Mike that incorporated "packet reordering" = in 10.2 and fixed a typo. The text is below. We can make this change = before we ship the draft to the editor. -acbegen Within End-Systems vs. within Middleboxes: When the FEC Framework is used within middleboxes, it is RECOMMENDED that the paths between the hosts where the sending applications run and the middlebox that performs FEC encoding be as reliable as possible, i.e., are not prone to packet loss, packet reordering, or varying delays in delivering packets. =20 Similarly, it is RECOMMENDED that the paths between the middleboxes that perform FEC decoding and the end-systems where the receiving applications operate, in situations where this is a different host, be as reliable as possible. The recommendation for the sending side is particularly important with FEC schemes that do not modify the ADU for backward compatibility purposes (i.e. do not use any Explicit Source FEC Payload ID) and rely for instance on the RTP sequence number field to identify FEC source packets within their source block. In this case, packet loss or packet reordering leads to a gap in the RTP sequence number space seen by the FECFRAME instance. Similarly, varying delay in delivering packets over this path can lead to significant timing and other issues. With FEC schemes that indicate in the Repair FEC Payload ID, for each source block, the base RTP sequence number and number of consecutive RTP packets that belong to this source block, a missing ADU or an ADU delivered out of order could cause the FECFRAME sender to switch to a new source block. However, some FEC schemes and/or receivers may not necessarily handle such varying source block sizes. Thus, all the ADUs SHOULD be fed into the FEC encoder in their proper sequence and within a desired certain delay. For cases when this cannot be guaranteed, the sender and receiver implementations need to consider a potential solution and its consequences. > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Tuesday, February 15, 2011 8:40 PM > To: Ali C. Begen (abegen); Greg Shepherd > Cc: Romascanu, Dan (Dan); Sean Turner; Russ Housley; fecframe@ietf.org > Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe >=20 > Looks good. One thing that I still think worth adding is something = about > potential packet reordering, i.e., whereever loss is an issue it = perhaps > should be mentioned that packet reordering can also be an issue that = needs > to be considered addressed. This is all wrt the Management/Deployment > section.=20 From abhishek.anand-ext@st.com Thu Feb 17 02:58:43 2011 Return-Path: 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 4002A3A6C85 for ; Thu, 17 Feb 2011 02:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 k1hAy3wHporw for ; Thu, 17 Feb 2011 02:58:40 -0800 (PST) Received: from eu1sys200aog118.obsmtp.com (eu1sys200aog118.obsmtp.com [207.126.144.145]) by core3.amsl.com (Postfix) with ESMTP id D23803A6B59 for ; Thu, 17 Feb 2011 02:58:38 -0800 (PST) Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob118.postini.com ([207.126.147.11]) with SMTP ID DSNKTVz/bytomHsgsp6dZ0LIU8ZzKmlhTce7@postini.com; Thu, 17 Feb 2011 10:59:09 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 6BB14340 for ; Thu, 17 Feb 2011 10:58:55 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas1.st.com [10.75.90.14]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 20D2E214A for ; Thu, 17 Feb 2011 10:58:55 +0000 (GMT) Received: from SAFEX1MAIL3.st.com ([10.75.90.7]) by SAFEX1HUBCAS1.st.com ([10.75.90.14]) with mapi; Thu, 17 Feb 2011 11:58:54 +0100 From: Abhishek ANAND To: "fecframe@ietf.org" Date: Thu, 17 Feb 2011 12:03:52 +0100 Thread-Topic: [Fecframe] About the Generic Explicit Source FEC Payload ID Thread-Index: AcvOkaqek1o0wDpYQI+7wRNZYMl9GQ== Message-ID: <4D5D0098.1040206@st.com> References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4D5D00981040206stcom_" MIME-Version: 1.0 Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload ID 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: , X-List-Received-Date: Thu, 17 Feb 2011 10:58:43 -0000 --_000_4D5D00981040206stcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everyone, I am writing to introduce another scenario where we may use multiple FEC Sc= hemes to protect the same Source Packet flow. The particular scenario is on= e in which we protect multiple Source Packet flows together (in any possibl= e combination) using multiple FEC Schemes. Example: We have two flows F1 and F2 and two FEC Scheme instances FEC1 and FEC2 wher= e FEC1 protects the Source Packets from F1 and FEC2 protects the Source pac= kets from F1 as well as F2. This example can be extended to add additional = flows and schemes. One such scenario is using Layer Aware FEC for protecting layered streams s= uch as H.264 SVC/MVC ( http://www.hhi.fraunhofer.de/en/departments/image-pr= ocessing/image-communication/multimedia-transmission/layer-aware-forward-er= ror-correction-l-fec/ ). There could be other such use cases as well. In such cases even when the Source Packet flows are RTP flows we must add S= ource Packet Payload IDs. In addition we can not use the Generic Explicit S= ource FEC Payload ID as it is described in Section 5.3.1 of the FEC Framewo= rk Draft because the position of a Source Packet in the Source Block will n= ot be unique across all FEC Schemes. Another observation regarding the Generic Explicit Source FEC Payload ID, s= ince it does not contain the Source Block Number and relies solely on conse= cutive sequence numbers it seems that the corresponding Repair FEC Payload = IDs must also use the Initial Sequence Number of each Source Block instead = of the Source Block Number. Regards, Abhishek On 02/11/2011 03:14 PM, fecframe-request@ietf.org wrote: > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto= :fecframe-bounces@ietf.org] On Behalf Of Vincent Roca > Sent: Friday, February 11, 2011 4:03 AM > To: fecframe@ietf.org > Subject: [Fecframe] About the Generic Explicit Source FEC Payload ID > > Hi everybody, > > While preparing the new O&M section proposal with Ali, > we spotted two points we'd like to discuss. Here is the first > one. > > Point 1: about the "Generic Explicit Source FEC Payload ID" > ------------------------------------------------- > > Section 5.3.1. of the FECFRAME Framework I-D says: > > "In order to apply FEC protection using multiple FEC schemes to a > single source flow, all schemes have to use the same Explicit Source > FEC Payload ID format. In order to enable this, it is RECOMMENDED > that FEC schemes support the Generic Explicit Source FEC Payload ID > format described below." > > Then it explains what is meant by "Generic source FEC payload ID", > i.e. a two byte field, in network byte order, that contains a sequence > number shared by all FEC schemes. > > When reading 5.3.1, it is clear to me that this field is to be carried > in an **Explicit Source FEC Payload ID**, i.e. at the end of the packet. > Section 5.3.1 does not suggest to reuse any sequence number that > may exist in the application flow (like the RTP sequence number) to > achieve this goal. > > We also notice that the sentence is rather strong in what FEC Schemes > should define (it says "RECOMMENDED"). > > It turns out that none of the current FEC Schemes define such a > Generic Explicit FEC Payload ID. > Additionally, the only use-case where an application flow is > protected by two different AL-FEC codes and that is considered > by IETF is the DVB-IPTV (draft-ietf-fecframe-dvb-al-fec-04). In > that case the solution consists in reusing the RTP SN field, rather > than defining a "Generic source FEC payload ID". > > > So we see two options here: > 1- Extend section 5.3.1 recommendations so that, if the > application flow already includes a sequence number that > fulfills the requirements of section 5.3.1, then this field can > be used to fulfill the needs specified here. But this is not > strictly speaking a special case of Explicit FEC Payload ID > (nothing is added to source packets). Right. If there is a seqnum that can be used, it could be used and no chanc= es to the source packets at all. If not, we need to specify the format for = the generic source fec payload ID field. And the format we define in the fr= amework draft is RECOMMENDED to be used when an fec scheme desires to suppo= rt being able to be used with other FEC schemes jointly. In other words, if= an FEC scheme chooses a different format for the explicit source fec paylo= ad id, it won't be able to be used with other FEC schemes that also need an= explicit source fec payload id. This is not interoperability but for great= er good, I think we should RECOMMEND the generic format we will define. -acbegen > 2- or weaken current 5.3.1 recommendation: > Old text: > "In order to enable this, it is RECOMMENDED > that FEC schemes support the Generic Explicit Source FEC > Payload ID > format described below." > New text: > "When this feature is desired, one solution can be for the FEC > schemes > to support the Generic Explicit Source FEC Payload ID format > described > below." > > Opinions? > > Cheers, > > Vincent and Ali. > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe -- Abhishek Anand Consultant STMicroelectronics - Torino - ITALY www.st.com Phone: +39 011 2276407 mailto: abhishek.anand-ext@st.com --_000_4D5D00981040206stcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hello everyone,

I am writing to introduce another scenario where we may use multiple FEC Schemes to protect the same Source Packet flow. The particular scenario is one in which we protect multiple Source Packet flows together (in any possible combination) using multiple FEC Schemes.

Example:
We have two flows F1 and F2 and two FEC Scheme instances FEC1 and FEC2 where FEC1 protects the Source Packets from F1 and FEC2 protects the Source packets from F1 as well as F2. This example can be extended to add additional flows and schemes.

One such scenario is using Layer Aware FEC for protecting layered streams such as H.264 SVC/MVC ( http://www.hhi.fraunhofer.de/en/= departments/image-processing/image-communication/multimedia-transmission/la= yer-aware-forward-error-correction-l-fec/ ). There could be other such use cases as well.

In such cases even when the Source Packet flows are RTP flows we must add Source Packet Payload IDs. In addition we can not use the Generic Explicit Source FEC Payload ID as it is described in Section 5.3.1 of the FEC Framework Draft because the position of a Source Packet in the Source Block will not be unique across all FEC Schemes.

Another observation regarding the Generic Explicit Source FEC Payload ID, since it does not contain the Source Block Number and relies solely on consecutive sequence numbers it seems that the corresponding Repair FEC Payload IDs must also use the Initial Sequence Number of each Source Block instead of the Source Block Number.

Regards,
Abhishek
 
On 02/11/2011 03:14 PM, fecframe-request@ietf.org wrote:
> -----Original Message-----
> From: fecframe-bounces@ietf.org [<= a moz-do-not-send=3D"true" href=3D"mailto:fecframe-bounces@ietf.org">mailto:= fecframe-bounces@ietf.org] On Behalf Of Vincent Roca
> Sent: Friday, February 11, 2011 4:03 AM
> To: fecframe@ietf.org
> Subject: [Fecframe] About the Generic Explicit Source FEC Payload ID
>
> Hi everybody,
>
> While preparing the new O&M section proposal with Ali,
> we spotted two points we'd like to discuss. Here is the first
> one.
>
> Point 1: about the "Generic Explicit Source FEC Payload ID"
> -------------------------------------------------
>
> Section 5.3.1. of the FECFRAME Framework I-D says:
>
>    "In order to apply FEC protection using multiple FEC= schemes to a
>     single source flow, all schemes have to use th= e same Explicit Source
>     FEC Payload ID format.  In order to enabl= e this, it is RECOMMENDED
>     that FEC schemes support the Generic Explicit = Source FEC Payload ID
>     format described below."
>
> Then it explains what is meant by "Generic source FEC payload ID",
> i.e. a two byte field, in network byte order, that contains a sequence
> number shared by all FEC schemes.
>
> When reading 5.3.1, it is clear to me that this field is to be carried
> in an **Explicit Source FEC Payload ID**, i.e. at the end of the packet.
> Section 5.3.1 does not suggest to reuse any sequence number that
> may exist in the application flow (like the RTP sequence number) to > achieve this goal.
>
> We also notice that the sentence is rather strong in what FEC Schemes
> should define (it says "RECOMMENDED").
>
> It turns out that none of the current FEC Schemes define such a
> Generic Explicit FEC Payload ID.
> Additionally, the only use-case where an application flow is
> protected by two different AL-FEC codes and that is considered
> by IETF is the DVB-IPTV (draft-ietf-fecframe-dvb-al-fec-04). In
> that case the solution consists in reusing the RTP SN field, rather > than defining a "Generic source FEC payload ID".
>
>
> So we see two options here:
> 1- Extend section 5.3.1 recommendations so that, if the
>      application flow already includes a sequ= ence number that
>      fulfills the requirements of section 5.3= .1, then this field can
>      be used to fulfill the needs specified h= ere. But this is not
>      strictly speaking a special case of Expl= icit FEC Payload ID
>      (nothing is added to source packets).
Right. If there is a seqnum that can be used, it could be used and no chances to the source packets at all. If not, we need to specify the format for the generic source fec payload ID field. And the format we define in the framework draft is RECOMMENDED to be used when an fec scheme desires to support being able to be used with other FEC schemes jointly. In other words, if an FEC scheme chooses a different format for the explicit source fec payload id, it won't be able to be used with other FEC schemes that also need an explicit source fec payload id. This is not interoperability but for greater good, I think we should RECOMMEND the generic format we will define.

-acbegen

> 2- or weaken current 5.3.1 recommendation:
> Old text:
>         "In order to enable th= is, it is RECOMMENDED
>          that FEC schemes= support the Generic Explicit Source FEC
> Payload ID
>          format described= below."
> New text:
>         "When this feature is = desired, one solution can be for the FEC
> schemes
>          to support the G= eneric Explicit Source FEC Payload ID format
> described
>          below."
>
> Opinions?
>
> Cheers,
>
>     Vincent and Ali.
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.o= rg/mailman/listinfo/fecframe


--=20
Abhishek Anand
Consultant
STMicroelectronics - Torino - ITALY
www.st.com=


Phone: +39 011 2276407=20
mailto: abhishek.anand-ext@st.com 



--_000_4D5D00981040206stcom_--

From abegen@cisco.com  Thu Feb 17 07:50:53 2011
Return-Path: 
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 0F9743A6F35 for ; Thu, 17 Feb 2011 07:50:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8]
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 cwfuJXT+AeUQ for ; Thu, 17 Feb 2011 07:50:51 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 73FDA3A6F43 for ; Thu, 17 Feb 2011 07:50:51 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag8BALPSXE2rR7H+/2dsb2JhbACXTY5Lc6Axm1IChVwEhQqKRg
X-IronPort-AV: E=Sophos;i="4.60,486,1291593600"; d="scan'208";a="311799595"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2011 15:51:22 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1HFpMJd009621; Thu, 17 Feb 2011 15:51:22 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.4675);  Thu, 17 Feb 2011 07:51:22 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Feb 2011 07:50:36 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E57BA28@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <4D5D0098.1040206@st.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] About the Generic Explicit Source FEC Payload ID
Thread-Index: AcvOkaqek1o0wDpYQI+7wRNZYMl9GQAJyflA
References:  <4D5D0098.1040206@st.com>
From: "Ali C. Begen (abegen)" 
To: "Abhishek ANAND" , 
X-OriginalArrivalTime: 17 Feb 2011 15:51:22.0515 (UTC) FILETIME=[86738E30:01CBCEBA]
Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload ID
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: , 
X-List-Received-Date: Thu, 17 Feb 2011 15:50:53 -0000

> -----Original Message-----
> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On =
Behalf Of Abhishek ANAND
> Sent: Thursday, February 17, 2011 6:04 AM
> To: fecframe@ietf.org
> Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload =
ID
>=20
> Hello everyone,
>=20
> I am writing to introduce another scenario where we may use multiple =
FEC Schemes to protect the same Source Packet flow.
> The particular scenario is one in which we protect multiple Source =
Packet flows together (in any possible combination) using
> multiple FEC Schemes.
>=20
> Example:
> We have two flows F1 and F2 and two FEC Scheme instances FEC1 and FEC2 =
where FEC1 protects the Source Packets from F1
> and FEC2 protects the Source packets from F1 as well as F2. This =
example can be extended to add additional flows and
> schemes.

Like figure 1 in =
https://datatracker.ietf.org/doc/rfc5956/?include_text=3D1 ?

> One such scenario is using Layer Aware FEC for protecting layered =
streams such as H.264 SVC/MVC (
> =
http://www.hhi.fraunhofer.de/en/departments/image-processing/image-commun=
ication/multimedia-transmission/layer-
> aware-forward-error-correction-l-fec/ ). There could be other such use =
cases as well.
>=20
> In such cases even when the Source Packet flows are RTP flows we must =
add Source Packet Payload IDs. In addition we can
> not use the Generic Explicit Source FEC Payload ID as it is described =
in Section 5.3.1 of the FEC Framework Draft because the
> position of a Source Packet in the Source Block will not be unique =
across all FEC Schemes.

Sorry, I don't understand this. The place of a source packet is derived =
from the information put in the repair packets, not source packets.

It should be sufficient to have the source packets seqnum'ed. And RTP =
satisfies that requirement nicely.

> Another observation regarding the Generic Explicit Source FEC Payload =
ID, since it does not contain the Source Block Number
> and relies solely on consecutive sequence numbers it seems that the =
corresponding Repair FEC Payload IDs must also use the
> Initial Sequence Number of each Source Block instead of the Source =
Block Number.

The generic field cannot carry the source block number as you said block =
sizes can and will vary among fecframe instances. And source block =
number is something used by the decoder but it is derived from the =
seqnum and base seqnum of a block (i.e., its value is not really used in =
an absolute fashion).

I am not sure whether you saw something in the text that said otherwise.

-acbegen
=20
> Regards,
> Abhishek
>=20
> On 02/11/2011 03:14 PM, fecframe-request@ietf.org wrote:
>=20
> 	> -----Original Message-----
> 	> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] =
On Behalf Of Vincent Roca
> 	> Sent: Friday, February 11, 2011 4:03 AM
> 	> To: fecframe@ietf.org
> 	> Subject: [Fecframe] About the Generic Explicit Source FEC Payload =
ID
> 	>
> 	> Hi everybody,
> 	>
> 	> While preparing the new O&M section proposal with Ali,
> 	> we spotted two points we'd like to discuss. Here is the first
> 	> one.
> 	>
> 	> Point 1: about the "Generic Explicit Source FEC Payload ID"
> 	> -------------------------------------------------
> 	>
> 	> Section 5.3.1. of the FECFRAME Framework I-D says:
> 	>
> 	>    "In order to apply FEC protection using multiple FEC schemes to =
a
> 	>     single source flow, all schemes have to use the same Explicit =
Source
> 	>     FEC Payload ID format.  In order to enable this, it is =
RECOMMENDED
> 	>     that FEC schemes support the Generic Explicit Source FEC =
Payload ID
> 	>     format described below."
> 	>
> 	> Then it explains what is meant by "Generic source FEC payload ID",
> 	> i.e. a two byte field, in network byte order, that contains a =
sequence
> 	> number shared by all FEC schemes.
> 	>
> 	> When reading 5.3.1, it is clear to me that this field is to be =
carried
> 	> in an **Explicit Source FEC Payload ID**, i.e. at the end of the =
packet.
> 	> Section 5.3.1 does not suggest to reuse any sequence number that
> 	> may exist in the application flow (like the RTP sequence number) to
> 	> achieve this goal.
> 	>
> 	> We also notice that the sentence is rather strong in what FEC =
Schemes
> 	> should define (it says "RECOMMENDED").
> 	>
> 	> It turns out that none of the current FEC Schemes define such a
> 	> Generic Explicit FEC Payload ID.
> 	> Additionally, the only use-case where an application flow is
> 	> protected by two different AL-FEC codes and that is considered
> 	> by IETF is the DVB-IPTV (draft-ietf-fecframe-dvb-al-fec-04). In
> 	> that case the solution consists in reusing the RTP SN field, rather
> 	> than defining a "Generic source FEC payload ID".
> 	>
> 	>
> 	> So we see two options here:
> 	> 1- Extend section 5.3.1 recommendations so that, if the
> 	>      application flow already includes a sequence number that
> 	>      fulfills the requirements of section 5.3.1, then this field =
can
> 	>      be used to fulfill the needs specified here. But this is not
> 	>      strictly speaking a special case of Explicit FEC Payload ID
> 	>      (nothing is added to source packets).
>=20
> 	Right. If there is a seqnum that can be used, it could be used and no =
chances to the source packets at all. If not, we
> need to specify the format for the generic source fec payload ID =
field. And the format we define in the framework draft is
> RECOMMENDED to be used when an fec scheme desires to support being =
able to be used with other FEC schemes jointly. In
> other words, if an FEC scheme chooses a different format for the =
explicit source fec payload id, it won't be able to be used
> with other FEC schemes that also need an explicit source fec payload =
id. This is not interoperability but for greater good, I
> think we should RECOMMEND the generic format we will define.
>=20
> 	-acbegen
>=20
> 	> 2- or weaken current 5.3.1 recommendation:
> 	> Old text:
> 	>         "In order to enable this, it is RECOMMENDED
> 	>          that FEC schemes support the Generic Explicit Source FEC
> 	> Payload ID
> 	>          format described below."
> 	> New text:
> 	>         "When this feature is desired, one solution can be for the =
FEC
> 	> schemes
> 	>          to support the Generic Explicit Source FEC Payload ID =
format
> 	> described
> 	>          below."
> 	>
> 	> Opinions?
> 	>
> 	> Cheers,
> 	>
> 	>     Vincent and Ali.
> 	> _______________________________________________
> 	> Fecframe mailing list
> 	> Fecframe@ietf.org
> 	> https://www.ietf.org/mailman/listinfo/fecframe
>=20
>=20
>=20
>=20
> --
> Abhishek Anand
> Consultant
> STMicroelectronics - Torino - ITALY
> www.st.com
>=20
> Phone: +39 011 2276407
> mailto: abhishek.anand-ext@st.com

From vincent.roca@inrialpes.fr  Thu Feb 17 09:29:50 2011
Return-Path: 
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 1A3C13A6DE3 for ; Thu, 17 Feb 2011 09:29:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.927
X-Spam-Level: 
X-Spam-Status: No, score=-9.927 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8]
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 8Sh0XQ-fMkBt for ; Thu, 17 Feb 2011 09:29:47 -0800 (PST)
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 622A33A6D60 for ; Thu, 17 Feb 2011 09:29:47 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.60,487,1291590000"; d="scan'208";a="88223715"
Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-de-roca.local) ([82.236.155.50]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 17 Feb 2011 18:30:16 +0100
Message-ID: <4D5D5089.8010309@inrialpes.fr>
Date: Thu, 17 Feb 2011 17:44:57 +0100
From: Vincent Roca 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "Ali C. Begen (abegen)" 
References: <04CAD96D4C5A3D48B1919248A8FE0D540E57B2CC@xmb-sjc-215.amer.cisco.com>	 <04CAD96D4C5A3D48B1919248A8FE0D540E57B925@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E57B925@xmb-sjc-215.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Russ Housley , Sean Turner , fecframe@ietf.org
Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe
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: , 
X-List-Received-Date: Thu, 17 Feb 2011 17:29:50 -0000

Ali, Mike, all,

A few comments:

>        Within End-Systems vs. within Middleboxes: When the FEC Framework
>        is used within middleboxes, it is RECOMMENDED that the paths
>        between the hosts where the sending applications run and the
>        middlebox that performs FEC encoding be as reliable as possible,
>        i.e., are not prone to packet loss, packet reordering, or varying
>        delays in delivering packets.
>
>        Similarly, it is RECOMMENDED that the paths between the
>        middleboxes that perform FEC decoding and the end-systems where
>        the receiving applications operate, in situations where this is a
>        different host, be as reliable as possible.
>
>        The recommendation for the sending side is particularly important
>        with FEC schemes that do not modify the ADU for backward
>        compatibility purposes (i.e. do not use any Explicit Source FEC
>        Payload ID) and rely for instance on the RTP sequence number field
>        to identify FEC source packets within their source block.  In this
>        case, packet loss or packet reordering
>        leads to a gap in the RTP sequence number space seen by the
VR: "lead" rather than "leads"
>        FECFRAME instance.  Similarly, varying delay in delivering packets
>        over this path can lead to significant timing and other issues.
VR: "and others"? That's too vague IMHO. Remove it.
>         With FEC schemes that indicate in the Repair
>        FEC Payload ID, for each source block, the base RTP sequence
>        number and number of consecutive RTP packets that belong to this
>        source block, a missing ADU or an ADU delivered out of order
>        could cause the FECFRAME sender to
>        switch to a new source block.
VR: rather than the following text...
>        However, some FEC schemes and/or
>        receivers may not necessarily handle such varying source block
>        sizes.  Thus, all the ADUs SHOULD be fed into the FEC encoder in
>        their proper sequence and within a desired certain delay.  For
>        cases when this cannot be guaranteed, the sender and receiver
>        implementations need to consider a potential solution and its
>        consequences.
VR: ...I suggest to say (since we have already RECOMMENDED this path
to be as reliable as possible and are only focusing on situations where
this is not achieved):

       However, some FEC schemes and/or receivers may not necessarily
       handle such varying source block sizes.
       In this case another solution SHOULD be considered that is use-case
       specific and whose consequences should be carefully considered
       (e.g., by duplicating the last packet received before the loss, or by
       inserting a zero'ed packet, depending on the ADU flow nature).

Cheers,

    Vincent

From luby@qualcomm.com  Thu Feb 17 09:33:44 2011
Return-Path: 
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 45C803A6D31 for ; Thu, 17 Feb 2011 09:33:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level: 
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 lnRCnBpYQuR2 for ; Thu, 17 Feb 2011 09:33:43 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 10DBF3A6C6A for ; Thu, 17 Feb 2011 09:33:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1297964054; x=1329500054; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Vi ncent=20Roca=20,=20"Ali=20C. =20Begen=20(abegen)"=0D=0A=09|CC:=20Gre g=20Shepherd=20,=20Sean=20Turner=20,=20Russ=0D=0A=20Housley=20,=20"fecframe@ietf.org"=20|Date: =20Thu,=2017=20Feb=202011=2009:34:09=20-0800|Subject:=20R e:=20[Fecframe]=20Ops/Management=20Cons.=20text=20for=20f ecframe|Thread-Topic:=20[Fecframe]=20Ops/Management=20Con s.=20text=20for=20fecframe|Thread-Index:=20AcvOyF5FYVQ3cl bWQWK5L/F3pFNCmgAAIOw5|Message-ID:=20|In-Reply-To:=20<4D5D5089.8010309@inrialpes. fr>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.8.0.101117|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=QTRUa1U6rJZl8QghUOaal8FNopOr84h0uWp572ncZDY=; b=ZPXyumccEG0IYv9HJtNMF7veTfdqt3jBA+aXZKjd8AFE8WueLavHZkAn 89DetjLqbOng3IzBJMYKWhysb+oh/6dBjKrB1GD3DWscGvOkaN0PinvfS bWsaVDg8qU2E7NZUNrGzZ9t55vD41B9j4XfkRKSxVfcaL2WJ1+JIqavDt A=;
X-IronPort-AV: E=McAfee;i="5400,1158,6259"; a="74821269"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 17 Feb 2011 09:34:14 -0800
X-IronPort-AV: E=Sophos;i="4.60,486,1291622400"; d="scan'208";a="116405707"
Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 17 Feb 2011 09:34:14 -0800
Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 17 Feb 2011 09:34:13 -0800
Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Thu, 17 Feb 2011 09:34:07 -0800
From: "Luby, Michael" 
To: Vincent Roca , "Ali C. Begen (abegen)" 
Date: Thu, 17 Feb 2011 09:34:09 -0800
Thread-Topic: [Fecframe] Ops/Management Cons. text for fecframe
Thread-Index: AcvOyF5FYVQ3clbWQWK5L/F3pFNCmgAAIOw5
Message-ID: 
In-Reply-To: <4D5D5089.8010309@inrialpes.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.8.0.101117
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Russ, Housley , Sean Turner , "fecframe@ietf.org" 
Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe
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: , 
X-List-Received-Date: Thu, 17 Feb 2011 17:33:44 -0000

Vincent, this is all good.
Best, Mike


On 2/17/11 8:44 AM, "Vincent Roca"  wrote:

> Ali, Mike, all,
>=20
> A few comments:
>=20
>>        Within End-Systems vs. within Middleboxes: When the FEC Framework
>>        is used within middleboxes, it is RECOMMENDED that the paths
>>        between the hosts where the sending applications run and the
>>        middlebox that performs FEC encoding be as reliable as possible,
>>        i.e., are not prone to packet loss, packet reordering, or varying
>>        delays in delivering packets.
>>=20
>>        Similarly, it is RECOMMENDED that the paths between the
>>        middleboxes that perform FEC decoding and the end-systems where
>>        the receiving applications operate, in situations where this is a
>>        different host, be as reliable as possible.
>>=20
>>        The recommendation for the sending side is particularly important
>>        with FEC schemes that do not modify the ADU for backward
>>        compatibility purposes (i.e. do not use any Explicit Source FEC
>>        Payload ID) and rely for instance on the RTP sequence number fiel=
d
>>        to identify FEC source packets within their source block.  In thi=
s
>>        case, packet loss or packet reordering
>>        leads to a gap in the RTP sequence number space seen by the
> VR: "lead" rather than "leads"
>>        FECFRAME instance.  Similarly, varying delay in delivering packet=
s
>>        over this path can lead to significant timing and other issues.
> VR: "and others"? That's too vague IMHO. Remove it.
>>         With FEC schemes that indicate in the Repair
>>        FEC Payload ID, for each source block, the base RTP sequence
>>        number and number of consecutive RTP packets that belong to this
>>        source block, a missing ADU or an ADU delivered out of order
>>        could cause the FECFRAME sender to
>>        switch to a new source block.
> VR: rather than the following text...
>>        However, some FEC schemes and/or
>>        receivers may not necessarily handle such varying source block
>>        sizes.  Thus, all the ADUs SHOULD be fed into the FEC encoder in
>>        their proper sequence and within a desired certain delay.  For
>>        cases when this cannot be guaranteed, the sender and receiver
>>        implementations need to consider a potential solution and its
>>        consequences.
> VR: ...I suggest to say (since we have already RECOMMENDED this path
> to be as reliable as possible and are only focusing on situations where
> this is not achieved):
>=20
>        However, some FEC schemes and/or receivers may not necessarily
>        handle such varying source block sizes.
>        In this case another solution SHOULD be considered that is use-cas=
e
>        specific and whose consequences should be carefully considered
>        (e.g., by duplicating the last packet received before the loss, or=
 by
>        inserting a zero'ed packet, depending on the ADU flow nature).
>=20
> Cheers,
>=20
>     Vincent


From abhishek.anand-ext@st.com  Fri Feb 18 02:25:20 2011
Return-Path: 
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 9B6693A6DB8 for ; Fri, 18 Feb 2011 02:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4]
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 EwAB+RU6TabP for ; Fri, 18 Feb 2011 02:25:18 -0800 (PST)
Received: from eu1sys200aog114.obsmtp.com (eu1sys200aog114.obsmtp.com [207.126.144.137]) by core3.amsl.com (Postfix) with ESMTP id 0404A3A6DBE for ; Fri, 18 Feb 2011 02:25:16 -0800 (PST)
Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob114.postini.com ([207.126.147.11]) with SMTP ID DSNKTV5JJHRgAdcQ9Oqsg+odL6TGT1DCPwq1@postini.com; Fri, 18 Feb 2011 10:25:51 UTC
Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 6CF1C3E1; Fri, 18 Feb 2011 10:25:28 +0000 (GMT)
Received: from Webmail-eu.st.com (safex1hubcas6.st.com [10.75.90.73]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 531E42C9F; Fri, 18 Feb 2011 10:25:28 +0000 (GMT)
Received: from SAFEX1MAIL3.st.com ([10.75.90.7]) by Safex1hubcas6.st.com ([10.75.90.73]) with mapi; Fri, 18 Feb 2011 11:25:27 +0100
From: Abhishek ANAND 
To: "Ali C. Begen (abegen)" 
Date: Fri, 18 Feb 2011 11:25:27 +0100
Thread-Topic: [Fecframe] About the Generic Explicit Source FEC Payload ID
Thread-Index: AcvPVilJkOiQ+QQTTNeXFKnA1dI/ng==
Message-ID: <4D5E4A44.4010206@st.com>
References:  <4D5D0098.1040206@st.com> <04CAD96D4C5A3D48B1919248A8FE0D540E57BA28@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E57BA28@xmb-sjc-215.amer.cisco.com>
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "fecframe@ietf.org" 
Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload ID
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: , 
X-List-Received-Date: Fri, 18 Feb 2011 10:25:20 -0000

On 02/17/2011 04:50 PM, Ali C. Begen (abegen) wrote:

 > -----Original Message-----
 > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On=20
Behalf Of Abhishek ANAND
 > Sent: Thursday, February 17, 2011 6:04 AM
 > To: fecframe@ietf.org
 > Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload ID
 >
 > Hello everyone,
 >
 > I am writing to introduce another scenario where we may use multiple=20
FEC Schemes to protect the same Source Packet flow.
 > The particular scenario is one in which we protect multiple Source=20
Packet flows together (in any possible combination) using
 > multiple FEC Schemes.
 >
 > Example:
 > We have two flows F1 and F2 and two FEC Scheme instances FEC1 and=20
FEC2 where FEC1 protects the Source Packets from F1
 > and FEC2 protects the Source packets from F1 as well as F2. This=20
example can be extended to add additional flows and
 > schemes.

abegen: Like figure 1 in=20
https://datatracker.ietf.org/doc/rfc5956/?include_text=3D1 ?

aanand: Yes like that, with LA-FEC being one such application. So in=20
addition to DVB ALFEC we have other potential technologies which might=20
use interdependent FECFrameworks.

 > One such scenario is using Layer Aware FEC for protecting layered=20
streams such as H.264 SVC/MVC (
 >=20
http://www.hhi.fraunhofer.de/en/departments/image-processing/image-communic=
ation/multimedia-transmission/layer-
 > aware-forward-error-correction-l-fec/ ). There could be other such=20
use cases as well.
 >
 > In such cases even when the Source Packet flows are RTP flows we must=20
add Source Packet Payload IDs. In addition we can
 > not use the Generic Explicit Source FEC Payload ID as it is described=20
in Section 5.3.1 of the FEC Framework Draft because the
 > position of a Source Packet in the Source Block will not be unique=20
across all FEC Schemes.

abegen: Sorry, I don't understand this. The place of a source packet is=20
derived from the information put in the repair packets, not source packets.

anand: I was of the opinion that the Source Packet's place is derived=20
from the information put in the Repair Packets only when they belong to=20
a single sequenced flow. In this case the Repair FEC Payload ID carries=20
the Initial Sequence Number which is used to place the Source Packet in=20
its place. In other cases where the Source Packets are not sequenced or=20
they belong to multiple arbitrary sequenced flows I believe the Source=20
Packet's place is calculated using the information present in the Source=20
Payload ID, such as Source Block Number and Encoding Symbol ID(ESI). I=20
think that is how the Raptor Schemes for DVB AL-FEC are designed. Also=20
"draft-roca-fecframe-simple-rs" defines one such FEC Scheme for Reed=20
Solomon codec where a FEC Source Packet MUST contain the specified=20
Source FEC payload ID.

abegen: It should be sufficient to have the source packets seqnum'ed.=20
And RTP satisfies that requirement nicely.

aanand: When we mix two RTP flows we loose the unique sequence number=20
sequences which would have been otherwise used by the FECFrameworks at=20
the sender and the receiver to place Source Packets. This problem=20
together with my opinion above makes it difficult to use the Generic=20
Explicit Source FEC Payload ID which is based on sequence numbers that=20
are unique across the FECFrameworks.
For example:
Lets continue the example with flows F1, F2 and frameworks FEC1, FEC2.
We add the following assumptions:
FEC1 uses Source Blocks of length 3 and FEC2 of length 6.
RTP sequence numbers for F1: 1,2,3
RTP sequence numbers for F2: 3,4,5.
I think RTP sequence numbers or any unique "consecutive/"/ sequence=20
numbers across all FECFrameworks can not be used to place the Source=20
Packets in the Source Block for FEC2, so we must add Source FEC Payload=20
IDs.

Maybe I am missing some points, in that case I apologize for my ignorance.

 > Another observation regarding the Generic Explicit Source FEC Payload=20
ID, since it does not contain the Source Block Number
 > and relies solely on consecutive sequence numbers it seems that the=20
corresponding Repair FEC Payload IDs must also use the
 > Initial Sequence Number of each Source Block instead of the Source=20
Block Number.

abegen: The generic field cannot carry the source block number as you=20
said block sizes can and will vary among fecframe instances. And source=20
block number is something used by the decoder but it is derived from the=20
seqnum and base seqnum of a block (i.e., its value is not really used in=20
an absolute fashion). I am not sure whether you saw something in the=20
text that said otherwise.

aanand: It was just an observation because it means that some FEC=20
Schemes which explicitly mention a Source FEC Payload ID, Repair FEC=20
Payload ID combination not based on sequence numbers will not be usable=20
in the use cases of interdependent FECFrameworks. And if my points above=20
are correct we might not be able to use unique sequence numbers to place=20
Source Packets across all the interdependent FECFrameworks.

-acbegen

 > Regards,
 > Abhishek
 >
 > On 02/11/2011 03:14 PM, fecframe-request@ietf.org wrote:
 >
 > > -----Original Message-----
 > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org]=20
On Behalf Of Vincent Roca
 > > Sent: Friday, February 11, 2011 4:03 AM
 > > To: fecframe@ietf.org
 > > Subject: [Fecframe] About the Generic Explicit Source FEC Payload ID
 > >
 > > Hi everybody,
 > >
 > > While preparing the new O&M section proposal with Ali,
 > > we spotted two points we'd like to discuss. Here is the first
 > > one.
 > >
 > > Point 1: about the "Generic Explicit Source FEC Payload ID"
 > > -------------------------------------------------
 > >
 > > Section 5.3.1. of the FECFRAME Framework I-D says:
 > >
 > >    "In order to apply FEC protection using multiple FEC schemes to a
 > >     single source flow, all schemes have to use the same Explicit=20
Source
 > >     FEC Payload ID format.  In order to enable this, it is RECOMMENDED
 > >     that FEC schemes support the Generic Explicit Source FEC Payload I=
D
 > >     format described below."
 > >
 > > Then it explains what is meant by "Generic source FEC payload ID",
 > > i.e. a two byte field, in network byte order, that contains a sequence
 > > number shared by all FEC schemes.
 > >
 > > When reading 5.3.1, it is clear to me that this field is to be carried
 > > in an **Explicit Source FEC Payload ID**, i.e. at the end of the=20
packet.
 > > Section 5.3.1 does not suggest to reuse any sequence number that
 > > may exist in the application flow (like the RTP sequence number) to
 > > achieve this goal.
 > >
 > > We also notice that the sentence is rather strong in what FEC Schemes
 > > should define (it says "RECOMMENDED").
 > >
 > > It turns out that none of the current FEC Schemes define such a
 > > Generic Explicit FEC Payload ID.
 > > Additionally, the only use-case where an application flow is
 > > protected by two different AL-FEC codes and that is considered
 > > by IETF is the DVB-IPTV (draft-ietf-fecframe-dvb-al-fec-04). In
 > > that case the solution consists in reusing the RTP SN field, rather
 > > than defining a "Generic source FEC payload ID".
 > >
 > >
 > > So we see two options here:
 > > 1- Extend section 5.3.1 recommendations so that, if the
 > >      application flow already includes a sequence number that
 > >      fulfills the requirements of section 5.3.1, then this field can
 > >      be used to fulfill the needs specified here. But this is not
 > >      strictly speaking a special case of Explicit FEC Payload ID
 > >      (nothing is added to source packets).
 >
 >       Right. If there is a seqnum that can be used, it could be used=20
and no chances to the source packets at all. If not, we
 > need to specify the format for the generic source fec payload ID=20
field. And the format we define in the framework draft is
 > RECOMMENDED to be used when an fec scheme desires to support being=20
able to be used with other FEC schemes jointly. In
 > other words, if an FEC scheme chooses a different format for the=20
explicit source fec payload id, it won't be able to be used
 > with other FEC schemes that also need an explicit source fec payload=20
id. This is not interoperability but for greater good, I
 > think we should RECOMMEND the generic format we will define.
 >
 >       -acbegen
 >
 > > 2- or weaken current 5.3.1 recommendation:
 > > Old text:
 > >         "In order to enable this, it is RECOMMENDED
 > >          that FEC schemes support the Generic Explicit Source FEC
 > > Payload ID
 > >          format described below."
 > > New text:
 > >         "When this feature is desired, one solution can be for the FEC
 > > schemes
 > >          to support the Generic Explicit Source FEC Payload ID format
 > > described
 > >          below."
 > >
 > > Opinions?
 > >
 > > Cheers,
 > >
 > >     Vincent and Ali.
 > > _______________________________________________
 > > Fecframe mailing list
 > > Fecframe@ietf.org
 > > https://www.ietf.org/mailman/listinfo/fecframe
 >
 >
 >
 >
 > --
 > Abhishek Anand
 > Consultant
 > STMicroelectronics - Torino - ITALY
 > www.st.com
 >
 > Phone: +39 011 2276407
 > mailto: abhishek.anand-ext@st.com

.

From abegen@cisco.com  Fri Feb 18 06:35:46 2011
Return-Path: 
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 4E5643A6DC6 for ; Fri, 18 Feb 2011 06:35:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.278
X-Spam-Level: 
X-Spam-Status: No, score=-10.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8]
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 cjrOZ03fAhkD for ; Fri, 18 Feb 2011 06:35:45 -0800 (PST)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4BDEF3A6CAC for ; Fri, 18 Feb 2011 06:35:45 -0800 (PST)
Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJ4SXk2rRN+K/2dsb2JhbACmInOgSZs4hV4EhQuKRg
X-IronPort-AV: E=Sophos;i="4.62,187,1297036800"; d="scan'208";a="265825160"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 18 Feb 2011 14:36:17 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1IEaJBB018536; Fri, 18 Feb 2011 14:36:19 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.4675);  Fri, 18 Feb 2011 06:36:18 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 18 Feb 2011 06:35:26 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E57BE1D@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <4D5E4A44.4010206@st.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] About the Generic Explicit Source FEC Payload ID
Thread-Index: AcvPVilJkOiQ+QQTTNeXFKnA1dI/ngAIImmw
References:  <4D5D0098.1040206@st.com> <04CAD96D4C5A3D48B1919248A8FE0D540E57BA28@xmb-sjc-215.amer.cisco.com> <4D5E4A44.4010206@st.com>
From: "Ali C. Begen (abegen)" 
To: "Abhishek ANAND" 
X-OriginalArrivalTime: 18 Feb 2011 14:36:18.0849 (UTC) FILETIME=[34786910:01CBCF79]
Cc: fecframe@ietf.org
Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload ID
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: , 
X-List-Received-Date: Fri, 18 Feb 2011 14:35:46 -0000

>  > In such cases even when the Source Packet flows are RTP flows we =
must
> add Source Packet Payload IDs. In addition we can
>  > not use the Generic Explicit Source FEC Payload ID as it is =
described
> in Section 5.3.1 of the FEC Framework Draft because the
>  > position of a Source Packet in the Source Block will not be unique
> across all FEC Schemes.
>=20
> abegen: Sorry, I don't understand this. The place of a source packet =
is
> derived from the information put in the repair packets, not source =
packets.
>=20
> anand: I was of the opinion that the Source Packet's place is derived
> from the information put in the Repair Packets only when they belong =
to
> a single sequenced flow. In this case the Repair FEC Payload ID =
carries
> the Initial Sequence Number which is used to place the Source Packet =
in
> its place. In other cases where the Source Packets are not sequenced =
or
> they belong to multiple arbitrary sequenced flows I believe the Source
> Packet's place is calculated using the information present in the =
Source
> Payload ID, such as Source Block Number and Encoding Symbol ID(ESI). I

Note that not every FEC scheme is capable of protecting multiple source =
flows together since their repair payload IDs are only designed for a =
single sequenced source flow. If an FEC scheme wants to be able handle =
such scenarios, it needs to be designed that way.

One could put the multiple source flows and re-seqnum them outside the =
fecframe and then feed the resulting stream into the fec encoder. And =
yes, then the original seqnums (such as RTP seqnums) cannot be used. =
But, this has nothing to do with fecframe's capability of protecting =
multiple source flows together. Because, here you are still feeding a =
single flow into fecframe.

> think that is how the Raptor Schemes for DVB AL-FEC are designed. Also
> "draft-roca-fecframe-simple-rs" defines one such FEC Scheme for Reed
> Solomon codec where a FEC Source Packet MUST contain the specified
> Source FEC payload ID.
>=20
> abegen: It should be sufficient to have the source packets seqnum'ed.
> And RTP satisfies that requirement nicely.
>=20
> aanand: When we mix two RTP flows we loose the unique sequence number
> sequences which would have been otherwise used by the FECFrameworks at
> the sender and the receiver to place Source Packets. This problem
> together with my opinion above makes it difficult to use the Generic
> Explicit Source FEC Payload ID which is based on sequence numbers that
> are unique across the FECFrameworks.
> For example:
> Lets continue the example with flows F1, F2 and frameworks FEC1, FEC2.
> We add the following assumptions:
> FEC1 uses Source Blocks of length 3 and FEC2 of length 6.
> RTP sequence numbers for F1: 1,2,3
> RTP sequence numbers for F2: 3,4,5.
> I think RTP sequence numbers or any unique "consecutive/"/ sequence
> numbers across all FECFrameworks can not be used to place the Source
> Packets in the Source Block for FEC2, so we must add Source FEC =
Payload
> IDs.
>=20
> Maybe I am missing some points, in that case I apologize for my =
ignorance.

You could use an identifier for your source flows and this will allow =
you to use their original seqnums. And in the repair payload IDs, you =
could use those identifiers.
=20
>  > Another observation regarding the Generic Explicit Source FEC =
Payload
> ID, since it does not contain the Source Block Number
>  > and relies solely on consecutive sequence numbers it seems that the
> corresponding Repair FEC Payload IDs must also use the
>  > Initial Sequence Number of each Source Block instead of the Source
> Block Number.

Yes. However, if the fec scheme used source block number info during =
encoding, that means it added source fec payload IDs to reflect that =
number (i.e., it has modified the source packets and it did not use the =
generic payload id).
=20
> abegen: The generic field cannot carry the source block number as you
> said block sizes can and will vary among fecframe instances. And =
source
> block number is something used by the decoder but it is derived from =
the
> seqnum and base seqnum of a block (i.e., its value is not really used =
in
> an absolute fashion). I am not sure whether you saw something in the
> text that said otherwise.
>=20
> aanand: It was just an observation because it means that some FEC
> Schemes which explicitly mention a Source FEC Payload ID, Repair FEC
> Payload ID combination not based on sequence numbers will not be =
usable
> in the use cases of interdependent FECFrameworks. And if my points =
above
> are correct we might not be able to use unique sequence numbers to =
place
> Source Packets across all the interdependent FECFrameworks.

-acbegen

From abegen@cisco.com  Sat Feb 19 13:06:17 2011
Return-Path: 
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 F3BA33A6FC2 for ; Sat, 19 Feb 2011 13:06:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.259
X-Spam-Level: 
X-Spam-Status: No, score=-10.259 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8]
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 I4hgB5cM+hA5 for ; Sat, 19 Feb 2011 13:06:16 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 157A43A6F18 for ; Sat, 19 Feb 2011 13:06:16 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiwBAP+/X02rR7Ht/2dsb2JhbACXbo5Lc55smnCCfYJhBIUNikc
X-IronPort-AV: E=Sophos;i="4.62,192,1297036800"; d="scan'208";a="312664684"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 19 Feb 2011 21:06:53 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1JL6rBf003268; Sat, 19 Feb 2011 21:06:53 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.4675);  Sat, 19 Feb 2011 13:06:53 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 19 Feb 2011 13:06:48 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E6139C9@xmb-sjc-215.amer.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] Ops/Management Cons. text for fecframe
Thread-Index: AcvOyF5FYVQ3clbWQWK5L/F3pFNCmgAAIOw5AGv6q4A=
References: <4D5D5089.8010309@inrialpes.fr> 
From: "Ali C. Begen (abegen)" 
To: "Luby, Michael" , "Vincent Roca" 
X-OriginalArrivalTime: 19 Feb 2011 21:06:53.0176 (UTC) FILETIME=[EED4AF80:01CBD078]
Cc: Russ Housley , Sean Turner , fecframe@ietf.org
Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe
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: , 
X-List-Received-Date: Sat, 19 Feb 2011 21:06:17 -0000

Changes are made, but I am holding on submitting a revision to wait for =
the ADs' resolutions of their discusses.

-acbegen

> -----Original Message-----
> From: Luby, Michael [mailto:luby@qualcomm.com]
> Sent: Thursday, February 17, 2011 12:34 PM
> To: Vincent Roca; Ali C. Begen (abegen)
> Cc: Greg Shepherd; Sean Turner; Russ Housley; fecframe@ietf.org
> Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe
>=20
> Vincent, this is all good.
> Best, Mike
>=20
>=20
> On 2/17/11 8:44 AM, "Vincent Roca"  wrote:
>=20
> > Ali, Mike, all,
> >
> > A few comments:
> >
> >>        Within End-Systems vs. within Middleboxes: When the FEC =
Framework
> >>        is used within middleboxes, it is RECOMMENDED that the paths
> >>        between the hosts where the sending applications run and the
> >>        middlebox that performs FEC encoding be as reliable as =
possible,
> >>        i.e., are not prone to packet loss, packet reordering, or =
varying
> >>        delays in delivering packets.
> >>
> >>        Similarly, it is RECOMMENDED that the paths between the
> >>        middleboxes that perform FEC decoding and the end-systems =
where
> >>        the receiving applications operate, in situations where this =
is a
> >>        different host, be as reliable as possible.
> >>
> >>        The recommendation for the sending side is particularly =
important
> >>        with FEC schemes that do not modify the ADU for backward
> >>        compatibility purposes (i.e. do not use any Explicit Source =
FEC
> >>        Payload ID) and rely for instance on the RTP sequence number =
field
> >>        to identify FEC source packets within their source block.  =
In this
> >>        case, packet loss or packet reordering
> >>        leads to a gap in the RTP sequence number space seen by the
> > VR: "lead" rather than "leads"
> >>        FECFRAME instance.  Similarly, varying delay in delivering =
packets
> >>        over this path can lead to significant timing and other =
issues.
> > VR: "and others"? That's too vague IMHO. Remove it.
> >>         With FEC schemes that indicate in the Repair
> >>        FEC Payload ID, for each source block, the base RTP sequence
> >>        number and number of consecutive RTP packets that belong to =
this
> >>        source block, a missing ADU or an ADU delivered out of order
> >>        could cause the FECFRAME sender to
> >>        switch to a new source block.
> > VR: rather than the following text...
> >>        However, some FEC schemes and/or
> >>        receivers may not necessarily handle such varying source =
block
> >>        sizes.  Thus, all the ADUs SHOULD be fed into the FEC =
encoder in
> >>        their proper sequence and within a desired certain delay.  =
For
> >>        cases when this cannot be guaranteed, the sender and =
receiver
> >>        implementations need to consider a potential solution and =
its
> >>        consequences.
> > VR: ...I suggest to say (since we have already RECOMMENDED this path
> > to be as reliable as possible and are only focusing on situations =
where
> > this is not achieved):
> >
> >        However, some FEC schemes and/or receivers may not =
necessarily
> >        handle such varying source block sizes.
> >        In this case another solution SHOULD be considered that is =
use-case
> >        specific and whose consequences should be carefully =
considered
> >        (e.g., by duplicating the last packet received before the =
loss, or by
> >        inserting a zero'ed packet, depending on the ADU flow =
nature).
> >
> > Cheers,
> >
> >     Vincent


From abhishek.anand-ext@st.com  Mon Feb 21 07:24:10 2011
Return-Path: 
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 D5E173A7126 for ; Mon, 21 Feb 2011 07:24:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.148
X-Spam-Level: 
X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4]
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 WajTvE3GUxqG for ; Mon, 21 Feb 2011 07:24:09 -0800 (PST)
Received: from eu1sys200aog112.obsmtp.com (eu1sys200aog112.obsmtp.com [207.126.144.133]) by core3.amsl.com (Postfix) with ESMTP id 39C663A7115 for ; Mon, 21 Feb 2011 07:24:07 -0800 (PST)
Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob112.postini.com ([207.126.147.11]) with SMTP ID DSNKTWKDuJWhqdGn8N+Rt6uETTyGo4NBY8J7@postini.com; Mon, 21 Feb 2011 15:24:50 UTC
Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 594FDEB; Mon, 21 Feb 2011 15:24:39 +0000 (GMT)
Received: from Webmail-eu.st.com (safex1hubcas2.st.com [10.75.90.16]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B4B652B96; Mon, 21 Feb 2011 15:24:38 +0000 (GMT)
Received: from SAFEX1MAIL3.st.com ([10.75.90.7]) by SAFEX1HUBCAS2.st.com ([10.75.90.16]) with mapi; Mon, 21 Feb 2011 16:24:38 +0100
From: Abhishek ANAND 
To: "Ali C. Begen (abegen)" 
Date: Mon, 21 Feb 2011 16:24:37 +0100
Thread-Topic: [Fecframe] About the Generic Explicit Source FEC Payload ID
Thread-Index: AcvR23NmJLK6x5t0S4CA6wmhltBttw==
Message-ID: <4D6284E7.2040203@st.com>
References:  <4D5D0098.1040206@st.com> <04CAD96D4C5A3D48B1919248A8FE0D540E57BA28@xmb-sjc-215.amer.cisco.com> <4D5E4A44.4010206@st.com> <04CAD96D4C5A3D48B1919248A8FE0D540E57BE1D@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E57BE1D@xmb-sjc-215.amer.cisco.com>
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_4D6284E72040203stcom_"
MIME-Version: 1.0
Cc: "fecframe@ietf.org" 
Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload ID
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: , 
X-List-Received-Date: Mon, 21 Feb 2011 15:24:10 -0000

--_000_4D6284E72040203stcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

>  > In such cases even when the Source Packet flows are RTP flows we must
> add Source Packet Payload IDs. In addition we can
>  > not use the Generic Explicit Source FEC Payload ID as it is described
> in Section 5.3.1 of the FEC Framework Draft because the
>  > position of a Source Packet in the Source Block will not be unique
> across all FEC Schemes.
>
> abegen: Sorry, I don't understand this. The place of a source packet is
> derived from the information put in the repair packets, not source packet=
s.
>
> anand: I was of the opinion that the Source Packet's place is derived
> from the information put in the Repair Packets only when they belong to
> a single sequenced flow. In this case the Repair FEC Payload ID carries
> the Initial Sequence Number which is used to place the Source Packet in
> its place. In other cases where the Source Packets are not sequenced or
> they belong to multiple arbitrary sequenced flows I believe the Source
> Packet's place is calculated using the information present in the Source
> Payload ID, such as Source Block Number and Encoding Symbol ID(ESI). I

abegen: Note that not every FEC scheme is capable of protecting multiple so=
urce flows together since their repair payload IDs are only designed for a =
single sequenced source flow. If an FEC scheme wants to be able handle such=
 scenarios, it needs to be designed that way.

anand: On the contrary I believe that any FEC Scheme that is capable of pro=
tecting multiple source flows together must not rely on sequence numbers (R=
TP/Self-assigned seq no./Generic Source Payload ID in its current form). It=
 should use Payload IDs containing Source Block Numbers and ESIs so that th=
e Encoding Symbols can be placed correctly at the decoder/reciever.

abegen: One could put the multiple source flows and re-seqnum them outside =
the fecframe and then feed the resulting stream into the fec encoder. And y=
es, then the original seqnums (such as RTP seqnums) cannot be used. But, th=
is has nothing to do with fecframe's capability of protecting multiple sour=
ce flows together. Because, here you are still feeding a single flow into f=
ecframe.

anand: I agrees that re-sequence numbering is possible. But this has limite=
d use as the problems arise at the client. A Source Packet can not have the=
 same sequence number (RTP/Artificial Seq No.) for multiple FECFrameworks s=
imply because the sequence number sequence(assumed to be incremental by 1) =
will overlap with another such running sequences for other flows.
Example:
Let us assume that we resequence the F1 Source Packets as 1,2,3 and feed th=
em to FEC1 and FEC2. Now, FEC2 resequences the F2 Source Packets as 4,5,6. =
In this way we have two Source Blocks, one each for FEC1 and FEC2. Now when=
 we get the next set of Source Packets for F1 we can reseqnum them as 4,5,6=
 for FEC1 but not for FEC2. One can think of using different sequence numbe=
rs for the same flow for different frameworks. But then this information (o=
ne new sequence number for each framework) must be attached to the Source P=
acket, otherwise the decoder will not be able to place the Source Packets.

> think that is how the Raptor Schemes for DVB AL-FEC are designed. Also
> "draft-roca-fecframe-simple-rs" defines one such FEC Scheme for Reed
> Solomon codec where a FEC Source Packet MUST contain the specified
> Source FEC payload ID.
>
> abegen: It should be sufficient to have the source packets seqnum'ed.
> And RTP satisfies that requirement nicely.
>
> aanand: When we mix two RTP flows we loose the unique sequence number
> sequences which would have been otherwise used by the FECFrameworks at
> the sender and the receiver to place Source Packets. This problem
> together with my opinion above makes it difficult to use the Generic
> Explicit Source FEC Payload ID which is based on sequence numbers that
> are unique across the FECFrameworks.
> For example:
> Lets continue the example with flows F1, F2 and frameworks FEC1, FEC2.
> We add the following assumptions:
> FEC1 uses Source Blocks of length 3 and FEC2 of length 6.
> RTP sequence numbers for F1: 1,2,3
> RTP sequence numbers for F2: 3,4,5.
> I think RTP sequence numbers or any unique "consecutive/"/ sequence
> numbers across all FECFrameworks can not be used to place the Source
> Packets in the Source Block for FEC2, so we must add Source FEC Payload
> IDs.
>
> Maybe I am missing some points, in that case I apologize for my ignorance=
.

abegen: You could use an identifier for your source flows and this will all=
ow you to use their original seqnums. And in the repair payload IDs, you co=
uld use those identifiers.

anand: I think this will not work as you might attach in the repair payload=
 IDs the (FlowID,ISN) combination for each of the flows. However the inform=
ation about the position of each Source Packet is still not there as this i=
nformation only tells the ISN for each flow, but does not tell how the Sour=
ce Packets from multiple flows have been placed together to form the Source=
 Block at the encoding FECFramework.

>  > Another observation regarding the Generic Explicit Source FEC Payload
> ID, since it does not contain the Source Block Number
>  > and relies solely on consecutive sequence numbers it seems that the
> corresponding Repair FEC Payload IDs must also use the
>  > Initial Sequence Number of each Source Block instead of the Source
> Block Number.

abegen: Yes. However, if the fec scheme used source block number info durin=
g encoding, that means it added source fec payload IDs to reflect that numb=
er (i.e., it has modified the source packets and it did not use the generic=
 payload id).

anand: My motive behind opening this discussion was to discuss if we can de=
fine a generic payload id that can be also used for the cases such as LA-FE=
C. Such cases are not outside the scope of FECFramework but I think current=
ly we do not have a formally defined way of handling them. I think such a S=
ource FEC Payload ID must combine the Source FEC Payload IDs of the individ=
ual FEC schemes that have been used to encode the Source Packet.

> abegen: The generic field cannot carry the source block number as you
> said block sizes can and will vary among fecframe instances. And source
> block number is something used by the decoder but it is derived from the
> seqnum and base seqnum of a block (i.e., its value is not really used in
> an absolute fashion). I am not sure whether you saw something in the
> text that said otherwise.
>
> aanand: It was just an observation because it means that some FEC
> Schemes which explicitly mention a Source FEC Payload ID, Repair FEC
> Payload ID combination not based on sequence numbers will not be usable
> in the use cases of interdependent FECFrameworks. And if my points above
> are correct we might not be able to use unique sequence numbers to place
> Source Packets across all the interdependent FECFrameworks.

-acbegen

Regards,
Abhishek

--_000_4D6284E72040203stcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable




 =20



>=A0 > In such cases even when the Source Packet
flows are RTP flows we must

> add Source Packet Payload IDs. In addition we can

>=A0 > not use the Generic Explicit Source FEC Payload ID as it is
described

> in Section 5.3.1 of the FEC Framework Draft because the

>=A0 > position of a Source Packet in the Source Block will not be
unique

> across all FEC Schemes.

>

> abegen: Sorry, I don't understand this. The place of a source
packet is

> derived from the information put in the repair packets, not source
packets.

>

> anand: I was of the opinion that the Source Packet's place is
derived

> from the information put in the Repair Packets only when they
belong to

> a single sequenced flow. In this case the Repair FEC Payload ID
carries

> the Initial Sequence Number which is used to place the Source
Packet in

> its place. In other cases where the Source Packets are not
sequenced or

> they belong to multiple arbitrary sequenced flows I believe the
Source

> Packet's place is calculated using the information present in the
Source

> Payload ID, such as Source Block Number and Encoding Symbol
ID(ESI). I



abegen: Note that not every FEC scheme is capable of protecting
multiple source
flows together since their repair payload IDs are only designed for a
single sequenced source flow. If an FEC scheme wants to be able handle
such scenarios, it needs to be designed that way.


anand: On the contrary I believe that any FEC Scheme
that is capable of protecting multiple source flows together must not
rely on sequence numbers (RTP/Self-assigned seq no./Generic Source
Payload ID in its current form). It should use Payload IDs containing
Source Block Numbers and ESIs so that the Encoding Symbols can be
placed correctly at the decoder/reciever.




abegen: One could put the multiple source flows and
re-seqnum them outside the
fecframe and then feed the resulting stream into the fec encoder. And
yes, then the original seqnums (such as RTP seqnums) cannot be used.
But, this has nothing to do with fecframe's capability of protecting
multiple source flows together. Because, here you are still feeding a
single flow into fecframe.


anand: I agrees that re-sequence numbering is
possible. But this has limited use as the problems arise at the client.
A Source Packet can not have the same sequence number (RTP/Artificial
Seq No.) for multiple FECFrameworks simply because the sequence number
sequence(assumed to be incremental by 1) will overlap with another such
running sequences for other flows. 

Example:

Let us assume that we resequence the F1 Source Packets as 1,2,3 and
feed them to FEC1 and FEC2. Now, FEC2 resequences the F2 Source Packets
as 4,5,6. In this way we have two Source Blocks, one each for FEC1 and
FEC2. Now when we get the next set of Source Packets for F1 we can
reseqnum them as 4,5,6 for FEC1 but not for FEC2. One can think of
using different sequence numbers for the same flow for different
frameworks. But then this information (one new sequence number for each
framework) must be attached to the Source Packet, otherwise the decoder
will not be able to place the Source Packets. 


> think that is how the Raptor Schemes for DVB
AL-FEC are designed. Also

> "draft-roca-fecframe-simple-rs" defines one such FEC Scheme for
Reed

> Solomon codec where a FEC Source Packet MUST contain the specified

> Source FEC payload ID.

>

> abegen: It should be sufficient to have the source packets
seqnum'ed.

> And RTP satisfies that requirement nicely.

>

> aanand: When we mix two RTP flows we loose the unique sequence
number

> sequences which would have been otherwise used by the
FECFrameworks at

> the sender and the receiver to place Source Packets. This problem

> together with my opinion above makes it difficult to use the
Generic

> Explicit Source FEC Payload ID which is based on sequence numbers
that

> are unique across the FECFrameworks.

> For example:

> Lets continue the example with flows F1, F2 and frameworks FEC1,
FEC2.

> We add the following assumptions:

> FEC1 uses Source Blocks of length 3 and FEC2 of length 6.

> RTP sequence numbers for F1: 1,2,3

> RTP sequence numbers for F2: 3,4,5.

> I think RTP sequence numbers or any unique "consecutive/"/ sequence
> numbers across all FECFrameworks can not be used to place the
Source

> Packets in the Source Block for FEC2, so we must add Source FEC
Payload

> IDs.

>

> Maybe I am missing some points, in that case I apologize for my
ignorance.



abegen: You could use an identifier for your source flows and this will
allow
you to use their original seqnums. And in the repair payload IDs, you
could use those identifiers.




anand: I think this will not work as you might attach
in the repair payload IDs the (FlowID,ISN) combination for each of the
flows. However the information about the position of each Source Packet
is still not there as this information only tells the ISN for each
flow, but does not tell how the Source Packets from multiple flows have
been placed together to form the Source Block at the encoding
FECFramework.




>=A0 > Another observation regarding the Generic
Explicit Source FEC Payload

> ID, since it does not contain the Source Block Number

>=A0 > and relies solely on consecutive sequence numbers it seems
that the

> corresponding Repair FEC Payload IDs must also use the

>=A0 > Initial Sequence Number of each Source Block instead of the
Source

> Block Number.



abegen: Yes. However, if the fec scheme used source block number info
during
encoding, that means it added source fec payload IDs to reflect that
number (i.e., it has modified the source packets and it did not use the
generic payload id).


anand: My motive behind opening this discussion was
to discuss if we can define a generic payload id that can be also used
for the cases such as LA-FEC. Such cases are not outside the scope of
FECFramework but I think currently we do not have a  formally defined way of handling
them. I think such a Source FEC Payload ID must combine the Source FEC
Payload IDs of the individual FEC schemes that have been used to encode
the Source Packet.




> abegen: The generic field cannot carry the
source block number as you

> said block sizes can and will vary among fecframe instances. And
source

> block number is something used by the decoder but it is derived
from the

> seqnum and base seqnum of a block (i.e., its value is not really
used in

> an absolute fashion). I am not sure whether you saw something in
the

> text that said otherwise.

>

> aanand: It was just an observation because it means that some FEC

> Schemes which explicitly mention a Source FEC Payload ID, Repair
FEC

> Payload ID combination not based on sequence numbers will not be
usable

> in the use cases of interdependent FECFrameworks. And if my points
above

> are correct we might not be able to use unique sequence numbers to
place

> Source Packets across all the interdependent FECFrameworks.



-acbegen




Regards,

Abhishek




--_000_4D6284E72040203stcom_--

From abegen@cisco.com  Mon Feb 21 07:36:03 2011
Return-Path: 
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 6F4443A7134 for ; Mon, 21 Feb 2011 07:36:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.243
X-Spam-Level: 
X-Spam-Status: No, score=-10.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8]
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 tRrtgPYzENlP for ; Mon, 21 Feb 2011 07:36:00 -0800 (PST)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0DE3A3A7139 for ; Mon, 21 Feb 2011 07:36:00 -0800 (PST)
Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALcUYk2rR7Ht/2dsb2JhbACmKnOfBZsUhV4EhQ2KRw
X-IronPort-AV: E=Sophos;i="4.62,200,1297036800"; d="scan'208";a="267747121"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 21 Feb 2011 15:36:41 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1LFafTI004384; Mon, 21 Feb 2011 15:36:41 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.4675);  Mon, 21 Feb 2011 07:36:41 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 21 Feb 2011 07:36:35 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E613B02@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <4D6284E7.2040203@st.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] About the Generic Explicit Source FEC Payload ID
Thread-Index: AcvR23NmJLK6x5t0S4CA6wmhltBttwAAM4gQ
References:  <4D5D0098.1040206@st.com> <04CAD96D4C5A3D48B1919248A8FE0D540E57BA28@xmb-sjc-215.amer.cisco.com> <4D5E4A44.4010206@st.com> <04CAD96D4C5A3D48B1919248A8FE0D540E57BE1D@xmb-sjc-215.amer.cisco.com> <4D6284E7.2040203@st.com>
From: "Ali C. Begen (abegen)" 
To: "Abhishek ANAND" 
X-OriginalArrivalTime: 21 Feb 2011 15:36:41.0742 (UTC) FILETIME=[231F42E0:01CBD1DD]
Cc: fecframe@ietf.org
Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload ID
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: , 
X-List-Received-Date: Mon, 21 Feb 2011 15:36:03 -0000

> abegen: Note that not every FEC scheme is capable of protecting =
multiple source flows together since their repair payload
> IDs are only designed for a single sequenced source flow. If an FEC =
scheme wants to be able handle such scenarios, it needs
> to be designed that way.
>=20
> anand: On the contrary I believe that any FEC Scheme that is capable =
of protecting multiple source flows together must not
> rely on sequence numbers (RTP/Self-assigned seq no./Generic Source =
Payload ID in its current form). It should use Payload
> IDs containing Source Block Numbers and ESIs so that the Encoding =
Symbols can be placed correctly at the decoder/reciever.

This is up to the designer of the code. If you wanna modify the source =
packets, feel free to but be aware of its implications.
=20
> abegen: One could put the multiple source flows and re-seqnum them =
outside the fecframe and then feed the resulting
> stream into the fec encoder. And yes, then the original seqnums (such =
as RTP seqnums) cannot be used. But, this has nothing
> to do with fecframe's capability of protecting multiple source flows =
together. Because, here you are still feeding a single flow
> into fecframe.
>=20
> anand: I agrees that re-sequence numbering is possible. But this has =
limited use as the problems arise at the client. A Source
> Packet can not have the same sequence number (RTP/Artificial Seq No.) =
for multiple FECFrameworks simply because the
> sequence number sequence(assumed to be incremental by 1) will overlap =
with another such running sequences for other
> flows.
> Example:
> Let us assume that we resequence the F1 Source Packets as 1,2,3 and =
feed them to FEC1 and FEC2. Now, FEC2 resequences
> the F2 Source Packets as 4,5,6. In this way we have two Source Blocks, =
one each for FEC1 and FEC2. Now when we get the
> next set of Source Packets for F1 we can reseqnum them as 4,5,6 for =
FEC1 but not for FEC2. One can think of using different
> sequence numbers for the same flow for different frameworks. But then =
this information (one new sequence number for
> each framework) must be attached to the Source Packet, otherwise the =
decoder will not be able to place the Source Packets.

Resequencing is something I mentioned if you wanted to turn multi-input =
into a single input. This does not relate to fecframe so we don't =
discuss it in the framework draft. Also after FEC is done, you need to =
de-sequence all those input streams somehow. That is also something we =
don't discuss within fecframe.
=20
> > think that is how the Raptor Schemes for DVB AL-FEC are designed. =
Also
> > "draft-roca-fecframe-simple-rs" defines one such FEC Scheme for Reed
> > Solomon codec where a FEC Source Packet MUST contain the specified
> > Source FEC payload ID.
> >
> > abegen: It should be sufficient to have the source packets =
seqnum'ed.
> > And RTP satisfies that requirement nicely.
> >
> > aanand: When we mix two RTP flows we loose the unique sequence =
number
> > sequences which would have been otherwise used by the FECFrameworks =
at
> > the sender and the receiver to place Source Packets. This problem
> > together with my opinion above makes it difficult to use the Generic
> > Explicit Source FEC Payload ID which is based on sequence numbers =
that
> > are unique across the FECFrameworks.
> > For example:
> > Lets continue the example with flows F1, F2 and frameworks FEC1, =
FEC2.
> > We add the following assumptions:
> > FEC1 uses Source Blocks of length 3 and FEC2 of length 6.
> > RTP sequence numbers for F1: 1,2,3
> > RTP sequence numbers for F2: 3,4,5.
> > I think RTP sequence numbers or any unique "consecutive/"/ sequence
> > numbers across all FECFrameworks can not be used to place the Source
> > Packets in the Source Block for FEC2, so we must add Source FEC =
Payload
> > IDs.
> >
> > Maybe I am missing some points, in that case I apologize for my =
ignorance.
>=20
> abegen: You could use an identifier for your source flows and this =
will allow you to use their original seqnums. And in the
> repair payload IDs, you could use those identifiers.
>=20
>=20
> anand: I think this will not work as you might attach in the repair =
payload IDs the (FlowID,ISN) combination for each of the
> flows. However the information about the position of each Source =
Packet is still not there as this information only tells the
> ISN for each flow, but does not tell how the Source Packets from =
multiple flows have been placed together to form the
> Source Block at the encoding FECFramework.

I think you are dismissing the fact that not everything is carried in =
band, meaning that we have something called configuration information.=20

Again, modifying the source packets in the way you would like to is not =
illegal, but unless absolutely necessary, pretty much nobody does it.
 =20
> >  > Another observation regarding the Generic Explicit Source FEC =
Payload
> > ID, since it does not contain the Source Block Number
> >  > and relies solely on consecutive sequence numbers it seems that =
the
> > corresponding Repair FEC Payload IDs must also use the
> >  > Initial Sequence Number of each Source Block instead of the =
Source
> > Block Number.
>=20
> abegen: Yes. However, if the fec scheme used source block number info =
during encoding, that means it added source fec
> payload IDs to reflect that number (i.e., it has modified the source =
packets and it did not use the generic payload id).
>=20
> anand: My motive behind opening this discussion was to discuss if we =
can define a generic payload id that can be also used
> for the cases such as LA-FEC. Such cases are not outside the scope of =
FECFramework but I think currently we do not have a
> formally defined way of handling them. I think such a Source FEC =
Payload ID must combine the Source FEC Payload IDs of the
> individual FEC schemes that have been used to encode the Source =
Packet.

If different schemes use different payload IDs for the source packets, =
it won't work. If you wanna change the content of the generic payload =
ID, I am still not seeing the need for it.

-acbegen