From ietfdbh@comcast.net Sun May 15 08:47:46 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711BCE06CB for ; Sun, 15 May 2011 08:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.127 X-Spam-Level: X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duR7VZWcsl7q for ; Sun, 15 May 2011 08:47:45 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF26E06CA for ; Sun, 15 May 2011 08:47:45 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id jrmh1g00B1swQuc55rnl7B; Sun, 15 May 2011 15:47:45 +0000 Received: from davidPC ([67.189.235.106]) by omta15.westchester.pa.mail.comcast.net with comcast id jrnl1g00F2JQnJT3brnlUN; Sun, 15 May 2011 15:47:45 +0000 From: "David Harrington" To: "'Ali C. Begen \(abegen\)'" References: <04CAD96D4C5A3D48B1919248A8FE0D540E6BFF29@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E6BFF29@xmb-sjc-215.amer.cisco.com> Date: Sun, 15 May 2011 11:47:31 -0400 Message-ID: <6E6DD3D6F41C47A58CF034019CFBC63B@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-Index: AcvYcgSHX4Izzxi0QeayL1ccCJWuBw6nLuIw Cc: fecframe@ietf.org Subject: Re: [Fecframe] FEC Framework DISCUSSes (was RE: Ops/Management Cons. text for fecframe) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 15:47:46 -0000 Hi, I updated my DISCUSS for the -14- revision. I think it is still lacking. Part of the problem is that the recommendation section is written using passive voice rather than active voice, so it is unclear who should do what. It should be clearer what ***actions*** SHOULD be taken by the implementations of recievers, senders, and middleboxes. Here are my suggestions for 10.2: 1) OLD: 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 method or protocol that works well for all of them would be too complex to define. 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 is one of the main goals of the FEC Framework. However, this section gives some recommendations. NEW: 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 method or protocol that works well for all of them would be too complex to define. 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 is one of the main goals of the FEC Framework. However, this section gives some RECOMMENDATIONS. From RCF2119 "Best Current Practices for RFC Key Words": "SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." Where a technology is RECOMMENDED, an implementer SHOULD include the technology in their implementation, so end users will have the option of enabling it when the situation calls for it. If an implementer feels that their implementation is not likely to be used in the relevant scenario, that would be a valid reason not to implement the RECOMMENDED technology in their implementation. 2) OLD: 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 tools using (or used by) RTCP to operate and manage the FEC Framework instance along with the associated FEC schemes. NEW: 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, Implementations SHOULD make feedback information accessible via RTCP to enable users to take advantage of the tools using (or used by) RTCP to operate and manage the FEC Framework instance along with the associated FEC schemes. 3) OLD: 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. NEW: 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. Implementers SHOULD make feedback available using an in-band or out-of-band asynchronous reporting mechanism. A standardized reporting mechanism, such as syslog or SNMP notifications, is RECOMMENDED. 4) OLD: 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. NEW: 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 SHOULD be achieved by sending repair packets on a different transport-layer flow. In case of an RTP source flow, this SHOULD 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. 5) OLD: 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 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. In this case, another solution SHOULD be considered that is use-case specific and whose consequences need to be carefully considered (e.g., by duplicating the last ADU received before the loss, or by inserting a zero'ed ADU, depending on the ADU flow nature). I don't knowe how to propose a NEW section for this text, because I do not understand this text. The paragraph starts with "the recommendation is particularly importat, but then never seems to actually make a recommendation. and then it suggest that "another solution SHOULD" be used. Another as comperade to what? what is the first recommended solution? 6) In the next block, about protecting a single flow vs several flows globally, I don't see any recommendations about "the use of any particular technology or protocol for transporting FEC data, managing the hosts, signaling the configuration information or encoding the configuration information." or any discussion of "the questions of interoperability across vendors/use cases and whether defining mandatory to implement (but not mandatory to use) solutions is beneficial." 7) regarding ADU Bundles, the use of passive voice hurts this text: OLD "the repair flow(s) SHOULD only be received by receivers that are authorized to receive all the associated ADU flows." NEW: "receivers SHOULD drop the repair flow(s) unless they are authorized to receive all the associated ADU flows." I think this whole section could be substantially better if it was written using actionable recommendations. I think these proposed changes are a step toward more actionable recommendations. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Tuesday, March 01, 2011 7:38 PM > To: Sean Turner; Russ Housley; ietfdbh@comcast.net > Cc: fecframe@ietf.org; gjshep@gmail.com > Subject: FEC Framework DISCUSSes (was RE: [Fecframe] > Ops/Management Cons. text for fecframe) > > We are dangerously getting close to the submission deadline > and as the authors, we would like to complete this draft so > that remaining work can move forward. > > Russ, Sean, David, > > Could you please review the changes and let us know whether > you are ok with them or require further changes? > https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework > /ballot/ > > -acbegen > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Wednesday, February 16, 2011 5:14 AM > > To: Ali C. Begen (abegen); gjshep@gmail.com > > Cc: fecframe@ietf.org; Sean Turner; Russ Housley > > Subject: RE: [Fecframe] Ops/Management Cons. text for fecframe > > > > I cleared. > > > > Thank you for addressing my concerns. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Wednesday, February 16, 2011 12:09 AM > > > To: gjshep@gmail.com > > > Cc: Romascanu, Dan (Dan); fecframe@ietf.org; Sean Turner; > Russ Housley > > > Subject: RE: [Fecframe] Ops/Management Cons. text for fecframe > > > > > > Revision has been submitted. > > > > > > 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/ > > > > > > 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 > > > > > > > > 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 Mon May 16 12:08:08 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0EEE074F for ; Mon, 16 May 2011 12:08:08 -0700 (PDT) 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_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-i-pHc0FCDJ for ; Mon, 16 May 2011 12:08:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEECE0762 for ; Mon, 16 May 2011 12:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=13166; q=dns/txt; s=iport; t=1305572880; x=1306782480; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ki3yKvoTbFuAlN5MpcsvSONw17eZG5EJPS5XM3G7CXA=; b=eehFTbLDC8mzWNOe404AS0MiErm/yBMX4d4J6TWangStYYmMCXvEFhch vuI4lMhz6sLKBXg8qwXo3NoxR8o4KkBHktXMgZ6KR3msgB7Ed21I0n28u rcnE15HcyRWHikmHKqcC89jh51nnfShV51o83uDrmxIYnuPV4UluUbyuJ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAOh10U2rRDoG/2dsb2JhbACXS45Md4hwnxOeJ4MUGoJrBIZQjXmEE4ZK X-IronPort-AV: E=Sophos;i="4.65,220,1304294400"; d="scan'208";a="448702394" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 16 May 2011 19:07:59 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4GJ7xqk019712; Mon, 16 May 2011 19:07:59 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, 16 May 2011 12:07:59 -0700 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, 16 May 2011 12:07:52 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F0A7516@xmb-sjc-215.amer.cisco.com> In-Reply-To: <6E6DD3D6F41C47A58CF034019CFBC63B@davidPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FEC Framework DISCUSSes (was RE: [Fecframe] Ops/Management Cons. text for fecframe) Thread-Index: AcvYcgSHX4Izzxi0QeayL1ccCJWuBw6nLuIwADlwDvA= References: <04CAD96D4C5A3D48B1919248A8FE0D540E6BFF29@xmb-sjc-215.amer.cisco.com> <6E6DD3D6F41C47A58CF034019CFBC63B@davidPC> From: "Ali C. Begen (abegen)" To: "David Harrington" X-OriginalArrivalTime: 16 May 2011 19:07:59.0479 (UTC) FILETIME=[92576870:01CC13FC] Cc: fecframe@ietf.org Subject: Re: [Fecframe] FEC Framework DISCUSSes (was RE: Ops/Management Cons. text for fecframe) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 19:08:08 -0000 Hi David, > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Sunday, May 15, 2011 11:48 AM > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org; gjshep@gmail.com > Subject: RE: FEC Framework DISCUSSes (was RE: [Fecframe] = Ops/Management Cons. text for fecframe) >=20 > Hi, >=20 > I updated my DISCUSS for the -14- revision. > I think it is still lacking. >=20 > Part of the problem is that the recommendation section is written > using passive voice rather > than active voice, so it is unclear who should do what. It should be > clearer > what ***actions*** SHOULD be taken by the implementations of > recievers, senders, > and middleboxes. >=20 > Here are my suggestions for 10.2: >=20 > 1) > OLD: > 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 method or protocol that works > well > for all of them would be too complex to define. 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 is one of the main > goals > of the FEC Framework. However, this section gives some > recommendations. > NEW: > 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 method or protocol that works > well > for all of them would be too complex to define. 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 is one of the main > goals > of the FEC Framework. >=20 > However, this section gives some RECOMMENDATIONS. From RCF2119 > "Best > Current Practices for RFC Key Words": > "SHOULD This word, or the adjective "RECOMMENDED", mean that > there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood > and > carefully weighed before choosing a different course." > Where a technology is RECOMMENDED, an implementer SHOULD include > the > technology in their implementation, so end users will have > the option of enabling it when the situation calls for it. If an > implementer feels that their implementation is not likely to be > used > in the relevant scenario, that would be a valid reason not to > implement > the RECOMMENDED technology in their implementation. OK, we will make "recommendations" uppercase. =20 > 2) > OLD: > 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 tools > using (or used by) RTCP to operate and manage the FEC Framework > instance along with the associated FEC schemes. > NEW: > 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, > Implementations SHOULD make feedback information accessible via > RTCP to enable users to take advantage of the tools > using (or used by) RTCP to operate and manage the FEC Framework > instance along with the associated FEC schemes. This is also fine. =20 > 3) > OLD: > 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. > NEW: > 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 > Implementers SHOULD make feedback available using an in-band or > out-of-band asynchronous reporting mechanism. A standardized > reporting mechanism, such as syslog or SNMP notifications, is > RECOMMENDED. OK, will add this last paragraph. =20 > 4) > OLD: > 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. > NEW: > 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 SHOULD be achieved by sending repair > packets on > a different transport-layer flow. In case of an RTP source > flow, > this SHOULD 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. Actually, in case of RTP, source and repair flows can still be still in = different transport-layer flows. So, I suggest: "In case of RTP transport and if both source and repair packets will be = sent on the same transport-layer flow, this SHOULD be achieved by using = an RTP framing for FEC repair packets with a different payload type." Ok with this? =20 > 5) > OLD: > 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 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. In this > case, > another solution SHOULD be considered that is use-case specific > and whose consequences need to be carefully considered (e.g., by > duplicating the last ADU received before the loss, or by > inserting > a zero'ed ADU, depending on the ADU flow nature). >=20 > I don't knowe how to propose a NEW section for this text, because I do > not understand this text. > The paragraph starts with "the recommendation is particularly > importat, but then never seems to actually make a recommendation. and > then it suggest that "another solution SHOULD" be used. Another as > comperade to what? what is > the first recommended solution? So for the fec schemes that indicate a base seqnum and number of = consecutive RTP packets for each source block, there is no problem. A = missing/late ADU may cause the sender to ship a smaller source block. If = the fec scheme can handle this, this does not create a problem. A problem raises if the fec scheme cannot handle varying size of source = blocks. For those, a solution is to put empty ADUs or repeating the last = ADU to make up for the full size. Whether the implementer should do one = of these depends on the use case. I suggest: ... However, some FEC schemes and/or receivers may not necessarily = handle such varying source block sizes. In this case, one could = consider duplicating the last ADU received before the loss, or inserting = zero'ed ADU(s), depending on the ADU flow nature. Implementers SHOULD = consider the consequences of such alternative approaches based on their = use cases. =20 > 6) > In the next block, about protecting a single flow vs several flows > globally, I don't see any recommendations about > "the use of any particular technology or protocol for transporting FEC > data, managing the hosts, > signaling the configuration information or encoding the > configuration information." or any discussion of > "the questions of interoperability across vendors/use cases and > whether defining mandatory to implement (but not mandatory to use) > solutions is beneficial." I do not think there is any interop consideration here. It only says if = you wanna protect multiple flows together, you need to pay attention to = the delay requirements of each flow. E.g., it would be simply wrong to = protect a real-time video flow with a non-real-time data flow if the FEC = encoding/decoding would render video packets late for arrival. =20 > 7) regarding ADU Bundles, the use of passive voice hurts this text: > OLD > "the repair flow(s) SHOULD only be received by > receivers that are authorized to receive all the associated ADU > flows." > NEW: > "receivers SHOULD drop the repair flow(s) unless they are > authorized to receive all the associated ADU > flows." Sounds good to me. =20 > I think this whole section could be substantially better if it was > written using actionable recommendations. I think these proposed > changes are a step toward more actionable recommendations. So, most of your changes look good to me, I will get them in. For a few, = I proposed an alternative text. Please let us know if you are ok with = them. -acbegen =20 >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) From vincent.roca@inrialpes.fr Wed May 18 04:13:39 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265DDE070F for ; Wed, 18 May 2011 04:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+-y1Se54Jy6 for ; Wed, 18 May 2011 04:13:37 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2D01FE06FE for ; Wed, 18 May 2011 04:13:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,230,1304287200"; d="scan'208";a="99274791" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 18 May 2011 13:13:34 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F0A7516@xmb-sjc-215.amer.cisco.com> Date: Wed, 18 May 2011 13:13:34 +0200 Content-Transfer-Encoding: 7bit Message-Id: <51848545-92E4-4230-A91D-18FC76CACD21@inrialpes.fr> References: <04CAD96D4C5A3D48B1919248A8FE0D540E6BFF29@xmb-sjc-215.amer.cisco.com> <6E6DD3D6F41C47A58CF034019CFBC63B@davidPC> <04CAD96D4C5A3D48B1919248A8FE0D540F0A7516@xmb-sjc-215.amer.cisco.com> To: David Harrington X-Mailer: Apple Mail (2.1084) Cc: fecframe@ietf.org Subject: Re: [Fecframe] FEC Framework DISCUSSes (was RE: Ops/Management Cons. text for fecframe) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 11:13:39 -0000 Hello David, > 1) > 2) I'm okay too. > 3) > [...] > > Implementers SHOULD make feedback available using an in-band or > out-of-band asynchronous reporting mechanism. A standardized > reporting mechanism, such as syslog or SNMP notifications, is > RECOMMENDED. I have several comments WRT the above paragraph. * syslog is standardized in RFC 5424, so we probably need to refer to this RFC, and similarly we need to refer to RFC 3411 for SNMP. Since implementing/using one of these protocols is RECOMMENDED, these references should go to the Normative References section (both are Standards Track documents, so there's no downward ref issue here). * Otherwise I'm a little confused by the juxtaposition of the two sentences. The first one says that an in-band solution, e.g. RTCP based, is RECOMMENDED (as one solution among others), while the second sentences RECOMMENDS the use of an out-of-band solution. If I put these two comments together, I would suggest something like: Implementers SHOULD make feedback available using either an in-band or out-of-band asynchronous reporting mechanism. When an out-of-band solution is preferred, a standardized reporting mechanism, such as syslog [RFC5424] or SNMP [RFC3411], is RECOMMENDED. * Is that sufficient to increase the probability that independent products interoperate? No, we need to go a bit further and define SNMP notification/syslog message formats. So the followup should be to start defining a MIB... Unless the implementer chooses an in-band, RTCP based, approach, which already includes useful information from the FECFRAME point of view. * We RECOMMEND two different out-of-band solutions, which creates interoperability risks. As I understand, mappings exist between the syslog/SNMP solution: RFC 5675 explains how to map SNMP notifications to syslog messages, while RFC 5676 discusses the opposite mapping. I don't know if these mappings are common or not, but this may also increase the probability that different products interoperate. So we can perhaps add a third sentence: When required, a mapping mechanism between the syslog and SNMP reporting mechanisms COULD be used, as described in [RFC5675] and [RFC5676]. > 4) I'm okay with your proposal plus Ali's update. > 5) I admit understanding this paragraph is somewhat difficult. The first RECOMMENDATION is within the first paragraph: ...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 This is only a RECOMMENDATION and in practice, for whatever reason, there MIGHT be a packet loss/reordering/delayed delivery on this path (i.e. sending application -> FECFRAME middlebox). Therefore the FECFRAME instance MUST NOT break if ever this happens, so we need to look a little bit further and give RECOMMENDATIONS on how to design a FEC Scheme that tolerates it. Just in case... It turns out the issue only arises with FEC Schemes that do NOT use any Explicit Source FPI (since there is no renumbering of symbols that are actually part of a source block). There are a few solutions (some of them mentioned). Which one is preferred is use-case specific (depends on the flow nature). IMO this discussion SHOULD be included in the framework document and any FEC Scheme that is concerned by the problem SHOULD at least highlight the general requirement and point to this framework discussion. Initial discussion: http://www.ietf.org/mail-archive/web/fecframe/current/msg00841.html More recently, WRT RTP for Raptor(Q): http://www.ietf.org/mail-archive/web/fecframe/current/msg00884.html The same applies to our draft-galanos-fecframe-rtp-reedsolomon-03 document, of course. In order to help clarify the point, here's what I suggest: NEW: At the sending side, the general reliability RECOMMENDATION for the path between the sending applications and the middlebox is important but it MAY NOT guaranty that a loss, reordering or important delivery delay cannot happen, for whatever reason. If such a rare event happens, this event SHOULD NOT compromize the operation of the FECFRAME instances, neither at the sending nor receiving side. This 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 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. In this case, another solution SHOULD be considered that is use-case specific and whose consequences need to be carefully considered (e.g., by duplicating the last ADU received before the loss, or by inserting a zero'ed ADU, depending on the ADU flow nature). > 6) I agree with Ali's comment. > 7) regarding ADU Bundles, the use of passive voice hurts this text: > OLD > "the repair flow(s) SHOULD only be received by > receivers that are authorized to receive all the associated ADU > flows." >NEW: > "receivers SHOULD drop the repair flow(s) unless they are > authorized to receive all the associated ADU flows." No, the new text changes the initial intent. The "SHOULD" is for the sender, not for the receiver. Since there's a misunderstanding, this means that the original text is bad, so you can blame us for that. So here is a new proposal: OLD: 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. NEW: Therefore, when defining the bundle of ADU flows that are globally protected and when defining which receiver receives which flow, the sender SHOULD make sure that the ADU flow(s) and repair flow(s) of that bundle will only be received by receivers that are authorized to receive all the ADU flows of that bundle. Cheers, Vincent From gjshep@gmail.com Wed May 25 07:10:16 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41D8130021 for ; Wed, 25 May 2011 07:10:15 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM6qO+9Dt83I for ; Wed, 25 May 2011 07:10:14 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 30D60130020 for ; Wed, 25 May 2011 07:10:13 -0700 (PDT) Received: by bwz13 with SMTP id 13so7666086bwz.31 for ; Wed, 25 May 2011 07:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=hxM5Ek5dKg69BmEgxB9rpc9jnasUpfmQnKUPqrSFLmA=; b=c9JINMeGGZx5u5nq67oXaXar0IM7bD+088GGDpeshVNZdd5iSHv56/yiJ5mwLluyih jL4h8TMGEyWs5iRU9WhNFicI/hVuAtGRwYuyFmRdfWhVh//LgAfm/OAvEmwvSbyELFTf QEP8wu1CuF33sMdfj4Km9Axd8NJgkWxW2mFqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=hSw6pr/aFarTMZA9Pjgj3vpzpyZPc6dJKbqYE+iBtp5Bb18U2ewnHrVaiNlsfXmmAZ RpNZXFG+umsxctkHm1sP525iqZSLBp6IWlw2WIaT+V34FQqVF8oXpUCTLwotDVW8CV6U G656xWAhwV5kHGykyi2A5VRQe0iEU/jmwpuE0= MIME-Version: 1.0 Received: by 10.204.74.11 with SMTP id s11mr4456315bkj.43.1306332612958; Wed, 25 May 2011 07:10:12 -0700 (PDT) Received: by 10.204.112.12 with HTTP; Wed, 25 May 2011 07:10:12 -0700 (PDT) Date: Wed, 25 May 2011 07:10:12 -0700 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] raptor drafts' status X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 25 May 2011 14:10:16 -0000 Qualcomm, the owners of the Raptor FEC schemes, have issued new IPR statements for the Raptor draft in RMT in an attempt to simplify and clarify the previous statements in response to issues raised. Once these new IPR statements are cleared in RMT these IPR statements will be updated for the FECFrame Raptor drafts as well. Until then our Raptor drafts, draft-ietf-fecframe-raptor-04 and draft-ietf-fecframe-rtp-raptor-04, are on hold in process. In order to speed up the process in FECFrame can all of you please read the new IPR statements from Qualcomm over in RMT so that any issues you have can be raised now and resolved before the IPR statements get applied to the FECFrame drafts. That should accelerate our process once the IPR is applied and Shepherd writeup is updated. You can find the new IPR statements here: http://datatracker.ietf.org/ipr/1553/ Thanks!, Greg From ietfdbh@comcast.net Fri May 27 11:46:05 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E91E0716 for ; Fri, 27 May 2011 11:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtbyKySYWow2 for ; Fri, 27 May 2011 11:46:04 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id CA5A4E0671 for ; Fri, 27 May 2011 11:46:03 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta01.westchester.pa.mail.comcast.net with comcast id oeoT1g0091uE5Es51im4Wr; Fri, 27 May 2011 18:46:04 +0000 Received: from davidPC ([67.189.235.106]) by omta16.westchester.pa.mail.comcast.net with comcast id oilx1g00h2JQnJT3cim0ND; Fri, 27 May 2011 18:46:02 +0000 From: "David Harrington" To: "'David Harrington'" , References: In-Reply-To: Date: Fri, 27 May 2011 14:45:46 -0400 Message-ID: <1AE3EDC81930474486070BB42B24E8EF@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-Index: Acv+5ll9WpQJ5KYoTbmLQcd2w3Idbwdt4+Qw Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org Subject: Re: [Fecframe] AD review: draft-ietf-fecframe-config-signaling-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 18:46:05 -0000 Hi Ali, will you have a chance to work on this soon? I think these are almost all fairly simple editorial changes. Fixing these should make it easier to get through IESG Eval. Thanks, David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: fecframe-bounces@ietf.org > [mailto:fecframe-bounces@ietf.org] On Behalf Of David Harrington > Sent: Tuesday, April 19, 2011 7:06 PM > To: fecframe@ietf.org > Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org > Subject: [Fecframe] AD review: draft-ietf-fecframe-config-signaling-04 > > Hi, > > I have performed AD Review on draft-ietf-fecframe-config-signaling-04. > > -- Technical and/or process concerns: > > 1) please check id-nits. There are some reported problems with > references, and example addresses. > > 2) Why is this document being requested to be published as > Experimental? Is there a lack of WG consensus for this design, or the > protocols discussed? If so, the concerns that prevent consensus from > being reached should be discussed, > probably with an explanation in the Introduction that this is an > Experimental proposal, not a standard. > > 3) In section 5.1, provide a reference explaining the UDP port 9875. > If this is IANA-assigned, please describe this in the IANA > Considerations section. > > 4) In the last paragraph of 5.1, when a delete has been received, the > receiver SHOULD no longer use the config info. Why is this not a MUST? > > 5) in 5.2, the assertion is made that using a generic protocol is > "under investigation and may be covered by a separate document." Where > is this under investigation? What document do you think will cover > this? > > 6) It helps IANA if you identify by URL the registry you want modified > (http://www.iana.org/assignments/rtsp-parameters/rtsp-parameters.xml > RTSP/1.0 Option Tags), and include the specific fields that require > filling. > > 7) The IANA considerations refer to section 4.2.2, but there is no > section 4.2.2 in this document. > > Editorial comments: > "Independent of what all encoding formats supported by an FEC scheme," > should be reworded. > > section 5 uses a numbering scheme of (i), (b), (c). I suspect the > first should be (a). > > I don't understand the topology pictured in Figure 1. I understand the > text, but the figure doesn't convey the topology very well. > > The "simpler method" description in section 5.1.1 could use some > English language cleanup. > > > > > > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From abegen@cisco.com Fri May 27 12:10:56 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7978EE06B5 for ; Fri, 27 May 2011 12:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePm5fBFFMGfK for ; Fri, 27 May 2011 12:10:50 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF75E07D5 for ; Fri, 27 May 2011 12:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3810; q=dns/txt; s=iport; t=1306523450; x=1307733050; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jj67WN60JmC6nJsPgWWCL+sTMb98N3bHM96s2jZwYsE=; b=beUQIQv/XY7lr2CAj/CejUBuU38C8rSJwe5dEGT3Ig7QXhgkzIdVHL4e g0yjyzjUX20a1ciFEVt013qJavO2zdt6Cue92FWQEEJgMARuAcJgLbUo+ S643xdvXxySnUxr2Ll9dctYNQobl5ILFoqjsNhjAf3H5W56OhVnW9voe5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAPz1302rRDoH/2dsb2JhbABHCAaXb45Od6llnVKDFxqCbQSGY44kinE X-IronPort-AV: E=Sophos;i="4.65,281,1304294400"; d="scan'208";a="365713545" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 27 May 2011 19:10:50 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4RJAoaf001087; Fri, 27 May 2011 19:10:50 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); Fri, 27 May 2011 12:10:50 -0700 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, 27 May 2011 12:10:29 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F20D920@xmb-sjc-215.amer.cisco.com> In-Reply-To: <1AE3EDC81930474486070BB42B24E8EF@davidPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] AD review: draft-ietf-fecframe-config-signaling-04 Thread-Index: Acv+5ll9WpQJ5KYoTbmLQcd2w3Idbwdt4+QwAADv9iA= References: <1AE3EDC81930474486070BB42B24E8EF@davidPC> From: "Ali C. Begen (abegen)" To: "David Harrington" , X-OriginalArrivalTime: 27 May 2011 19:10:50.0094 (UTC) FILETIME=[CA9470E0:01CC1CA1] Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org Subject: Re: [Fecframe] AD review: draft-ietf-fecframe-config-signaling-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:10:56 -0000 Hi David,=20 I and then Vincent sent some comments to your email. Did you see them? I = was waiting for your response back. Thanks. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of David Harrington > Sent: Friday, May 27, 2011 2:46 PM > To: 'David Harrington'; fecframe@ietf.org > Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org > Subject: Re: [Fecframe] AD review: = draft-ietf-fecframe-config-signaling-04 >=20 > Hi Ali, >=20 > will you have a chance to work on this soon? > I think these are almost all fairly simple editorial changes. > Fixing these should make it easier to get through IESG Eval. >=20 > Thanks, > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 > > -----Original Message----- > > From: fecframe-bounces@ietf.org > > [mailto:fecframe-bounces@ietf.org] On Behalf Of David Harrington > > Sent: Tuesday, April 19, 2011 7:06 PM > > To: fecframe@ietf.org > > Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org > > Subject: [Fecframe] AD review: > draft-ietf-fecframe-config-signaling-04 > > > > Hi, > > > > I have performed AD Review on > draft-ietf-fecframe-config-signaling-04. > > > > -- Technical and/or process concerns: > > > > 1) please check id-nits. There are some reported problems with > > references, and example addresses. > > > > 2) Why is this document being requested to be published as > > Experimental? Is there a lack of WG consensus for this design, or > the > > protocols discussed? If so, the concerns that prevent consensus from > > being reached should be discussed, > > probably with an explanation in the Introduction that this is an > > Experimental proposal, not a standard. > > > > 3) In section 5.1, provide a reference explaining the UDP port 9875. > > If this is IANA-assigned, please describe this in the IANA > > Considerations section. > > > > 4) In the last paragraph of 5.1, when a delete has been received, > the > > receiver SHOULD no longer use the config info. Why is this not a > MUST? > > > > 5) in 5.2, the assertion is made that using a generic protocol is > > "under investigation and may be covered by a separate document." > Where > > is this under investigation? What document do you think will cover > > this? > > > > 6) It helps IANA if you identify by URL the registry you want > modified > > (http://www.iana.org/assignments/rtsp-parameters/rtsp-parameters.xml > > RTSP/1.0 Option Tags), and include the specific fields that require > > filling. > > > > 7) The IANA considerations refer to section 4.2.2, but there is no > > section 4.2.2 in this document. > > > > Editorial comments: > > "Independent of what all encoding formats supported by an FEC > scheme," > > should be reworded. > > > > section 5 uses a numbering scheme of (i), (b), (c). I suspect the > > first should be (a). > > > > I don't understand the topology pictured in Figure 1. I understand > the > > text, but the figure doesn't convey the topology very well. > > > > The "simpler method" description in section 5.1.1 could use some > > English language cleanup. > > > > > > > > > > > > > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > > _______________________________________________ > > 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 Fri May 27 12:24:06 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F35E06FD for ; Fri, 27 May 2011 12:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJLJXVit1eQw for ; Fri, 27 May 2011 12:24:05 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 34680E0794 for ; Fri, 27 May 2011 12:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=4693; q=dns/txt; s=iport; t=1306524245; x=1307733845; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=/HO8IwW1euq7rnv+BziYZMuritElrNmLzd00wSxZDGI=; b=Q8GNxRbY/wxJxBnuidct4MF3RPZDu3yac3ofnU/3BdthsHgIjIrOoaCv LhFa0bWcjB3vY4IND+tYFU+miXyOBzur++eNw90VI92yEsSoDkzGshXVY X6xzT7Rxeiroj2wZSxqYO0Q/7OL7aqt4YwzWVcE+GnrVT1uvyOX3Ganbk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAJz5302rRDoI/2dsb2JhbABHCAaXb45Od6oRnVCDFxqCbQSGY44kinE X-IronPort-AV: E=Sophos;i="4.65,281,1304294400"; d="scan'208";a="365720658" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 27 May 2011 19:24:04 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4RJO4XK018808; Fri, 27 May 2011 19:24:04 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, 27 May 2011 12:24:04 -0700 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, 27 May 2011 12:23:17 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F20D932@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F20D920@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] AD review: draft-ietf-fecframe-config-signaling-04 Thread-Index: Acv+5ll9WpQJ5KYoTbmLQcd2w3Idbwdt4+QwAADv9iAAAGkYMA== References: <1AE3EDC81930474486070BB42B24E8EF@davidPC> <04CAD96D4C5A3D48B1919248A8FE0D540F20D920@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "David Harrington" , X-OriginalArrivalTime: 27 May 2011 19:24:04.0718 (UTC) FILETIME=[A43670E0:01CC1CA3] Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org Subject: Re: [Fecframe] AD review: draft-ietf-fecframe-config-signaling-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 19:24:06 -0000 I apologize. I thought David was referring to the framework draft below = when I saw "Hi Ali" but this draft belongs to Rajiv. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Ali C. Begen (abegen) > Sent: Friday, May 27, 2011 3:10 PM > To: David Harrington; fecframe@ietf.org > Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org > Subject: Re: [Fecframe] AD review: = draft-ietf-fecframe-config-signaling-04 >=20 > Hi David, >=20 > I and then Vincent sent some comments to your email. Did you see them? = I was waiting for your response back. >=20 > Thanks. > -acbegen >=20 > > -----Original Message----- > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] = On Behalf Of David Harrington > > Sent: Friday, May 27, 2011 2:46 PM > > To: 'David Harrington'; fecframe@ietf.org > > Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org > > Subject: Re: [Fecframe] AD review: = draft-ietf-fecframe-config-signaling-04 > > > > Hi Ali, > > > > will you have a chance to work on this soon? > > I think these are almost all fairly simple editorial changes. > > Fixing these should make it easier to get through IESG Eval. > > > > Thanks, > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > > > -----Original Message----- > > > From: fecframe-bounces@ietf.org > > > [mailto:fecframe-bounces@ietf.org] On Behalf Of David Harrington > > > Sent: Tuesday, April 19, 2011 7:06 PM > > > To: fecframe@ietf.org > > > Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org > > > Subject: [Fecframe] AD review: > > draft-ietf-fecframe-config-signaling-04 > > > > > > Hi, > > > > > > I have performed AD Review on > > draft-ietf-fecframe-config-signaling-04. > > > > > > -- Technical and/or process concerns: > > > > > > 1) please check id-nits. There are some reported problems with > > > references, and example addresses. > > > > > > 2) Why is this document being requested to be published as > > > Experimental? Is there a lack of WG consensus for this design, or > > the > > > protocols discussed? If so, the concerns that prevent consensus = from > > > being reached should be discussed, > > > probably with an explanation in the Introduction that this is an > > > Experimental proposal, not a standard. > > > > > > 3) In section 5.1, provide a reference explaining the UDP port = 9875. > > > If this is IANA-assigned, please describe this in the IANA > > > Considerations section. > > > > > > 4) In the last paragraph of 5.1, when a delete has been received, > > the > > > receiver SHOULD no longer use the config info. Why is this not a > > MUST? > > > > > > 5) in 5.2, the assertion is made that using a generic protocol is > > > "under investigation and may be covered by a separate document." > > Where > > > is this under investigation? What document do you think will cover > > > this? > > > > > > 6) It helps IANA if you identify by URL the registry you want > > modified > > > = (http://www.iana.org/assignments/rtsp-parameters/rtsp-parameters.xml > > > RTSP/1.0 Option Tags), and include the specific fields that = require > > > filling. > > > > > > 7) The IANA considerations refer to section 4.2.2, but there is no > > > section 4.2.2 in this document. > > > > > > Editorial comments: > > > "Independent of what all encoding formats supported by an FEC > > scheme," > > > should be reworded. > > > > > > section 5 uses a numbering scheme of (i), (b), (c). I suspect the > > > first should be (a). > > > > > > I don't understand the topology pictured in Figure 1. I understand > > the > > > text, but the figure doesn't convey the topology very well. > > > > > > The "simpler method" description in section 5.1.1 could use some > > > English language cleanup. > > > > > > > > > > > > > > > > > > > > > David Harrington > > > Director, IETF Transport Area > > > ietfdbh@comcast.net (preferred for ietf) > > > dbharrington@huaweisymantec.com > > > +1 603 828 1401 (cell) > > > > > > _______________________________________________ > > > 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 From rajiva@cisco.com Mon May 30 20:01:59 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E09E06A1 for ; Mon, 30 May 2011 20:01:59 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4dkGbe8a3YV for ; Mon, 30 May 2011 20:01:58 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 87CFEE065D for ; Mon, 30 May 2011 20:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4105; q=dns/txt; s=iport; t=1306810918; x=1308020518; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oaJMUw8YVcakDJ9GeCR6zHvmawphxlHMTecjC72iV5s=; b=k/JKc7ugTpzBYvxdSsQtcCOB3yvgev/ZpUOcs2nIufBMQY6h2c4S+UFG LoOMsoaqN5dGODXGBjW4IxpIft+7VlN+jXo5OUgXrAH6c1BWDSLoPEj3N 8vlRn45/r/5c9WAnIff9M5hVt+K4lsOjdlLSxQOFvqudnadDVXNRrAuv+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggBAJFZ5E2tJXG//2dsb2JhbABFCAaXW45Pd4hxnSWdTYMXGoJtBIZkjjKKcQ X-IronPort-AV: E=Sophos;i="4.65,295,1304294400"; d="scan'208";a="456725357" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-1.cisco.com with ESMTP; 31 May 2011 03:01:57 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4V31vxx013396; Tue, 31 May 2011 03:01:57 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 May 2011 22:01:57 -0500 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: Mon, 30 May 2011 22:01:55 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C050FF1EB@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review: draft-ietf-fecframe-config-signaling-04 Thread-Index: Acv+5ll9WpQJ5KYoTbmLQcd2w3IdbwgBldDg References: From: "Rajiv Asati (rajiva)" To: "David Harrington" , X-OriginalArrivalTime: 31 May 2011 03:01:57.0363 (UTC) FILETIME=[1A6CA430:01CC1F3F] Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org Subject: Re: [Fecframe] AD review: draft-ietf-fecframe-config-signaling-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 03:01:59 -0000 Hi David, Thank you so much for your review and feedback. Sorry about the delay in getting back to you. I have incorporated your feedback in -05 version of the document. Would be glad to incorporate any other comments you may have.=20 Responding to your comments one-by-one: 1. Fixed the nits. 2. Fixed. Good catch, btw. The WGLC had concluded it being a PS.=20 3. UDP port 9875 is already IANA assigned for SAP. I have left the section 7 (IANA consideration) unchanged, but updated section 5.1 with the reference to RFC2974 and moved the whole para under the 1st para. 4. Fixed. Good catch. 5. Fixed. Aaah. That was a left-over from the discussion we had ~3yrs ago. It needed to be removed. Fixed the sentence.=20 6. Is the updated IANA section good enough? 7. Fixed. It was supposed to be section 5.2.2. Accommodated the editorial comments. > Editorial comments: > "Independent of what all encoding formats supported by an FEC scheme," > should be reworded. Fixed. Reworded to " Independent of the encoding formats supported..." =09 > section 5 uses a numbering scheme of (i), (b), (c). I suspect the > first should be (a). Fixed. Good catch. > I don't understand the topology pictured in Figure 1. I understand the > text, but the figure doesn't convey the topology very well. Would appreciate any suggestion you may have. > The "simpler method" description in section 5.1.1 could use some > English language cleanup. Fixed, but if you have further suggestions, then please don't hesitate. Cheers, Rajiv ~~~ June 8, 2011 is the "World IPv6 Day" (http://isoc.org/wp/worldipv6day/) > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, April 19, 2011 7:06 PM > To: fecframe@ietf.org > Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org > Subject: AD review: draft-ietf-fecframe-config-signaling-04 >=20 > Hi, >=20 > I have performed AD Review on draft-ietf-fecframe-config-signaling-04. >=20 > -- Technical and/or process concerns: >=20 > 1) please check id-nits. There are some reported problems with > references, and example addresses. >=20 > 2) Why is this document being requested to be published as > Experimental? Is there a lack of WG consensus for this design, or the > protocols discussed? If so, the concerns that prevent consensus from > being reached should be discussed, > probably with an explanation in the Introduction that this is an > Experimental proposal, not a standard. >=20 > 3) In section 5.1, provide a reference explaining the UDP port 9875. > If this is IANA-assigned, please describe this in the IANA > Considerations section. >=20 > 4) In the last paragraph of 5.1, when a delete has been received, the > receiver SHOULD no longer use the config info. Why is this not a MUST? >=20 > 5) in 5.2, the assertion is made that using a generic protocol is > "under investigation and may be covered by a separate document." Where > is this under investigation? What document do you think will cover > this? >=20 > 6) It helps IANA if you identify by URL the registry you want modified > (http://www.iana.org/assignments/rtsp-parameters/rtsp-parameters.xml > RTSP/1.0 Option Tags), and include the specific fields that require > filling. >=20 > 7) The IANA considerations refer to section 4.2.2, but there is no > section 4.2.2 in this document. >=20 > Editorial comments: > "Independent of what all encoding formats supported by an FEC scheme," > should be reworded. > =09 > section 5 uses a numbering scheme of (i), (b), (c). I suspect the > first should be (a). >=20 > I don't understand the topology pictured in Figure 1. I understand the > text, but the figure doesn't convey the topology very well. >=20 > The "simpler method" description in section 5.1.1 could use some > English language cleanup. >=20 >=20 >=20 >=20 >=20 >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) From internet-drafts@ietf.org Mon May 30 20:03:26 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159DDE0700; Mon, 30 May 2011 20:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6Onmj-AUoWk; Mon, 30 May 2011 20:03:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C27E0658; Mon, 30 May 2011 20:03:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110531030325.27745.1687.idtracker@ietfa.amsl.com> Date: Mon, 30 May 2011 20:03:25 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-config-signaling-05.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 03:03:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IE= TF. Title : Methods to convey FEC Framework Configuration Information Author(s) : Rajiv Asati Filename : draft-ietf-fecframe-config-signaling-05.txt Pages : 17 Date : 2011-05-30 FEC Framework document [FECARCH] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes how to use existing signaling protocols to determine and dynamically communicate the Configuration information between sender(s) and receiver(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-config-signaling-05= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-config-signaling-05.= txt