From fecframe-bounces@ietf.org Mon Oct 09 16:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1gi-00016v-OA; Mon, 09 Oct 2006 16:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1gh-00016j-IA for fecframe@ietf.org; Mon, 09 Oct 2006 16:25:23 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX1ge-00066l-Vl for fecframe@ietf.org; Mon, 09 Oct 2006 16:25:23 -0400 Received: by ug-out-1314.google.com with SMTP id 72so606345ugd for ; Mon, 09 Oct 2006 13:25:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YhDSo7f3ShrhJ47EtUMcIPNcjeRxzcqNzvSIzR4Bp75Ggw7vYJ7KPqv+da46fe8sLiQHkJ4MkHkJKGFTJsQVtmT6Q1Gp6w8LFRo7ZI+R2W1rTZ3Bv2vWYGbrP91AUC6LgBc9y87aQKUkia/EQff2mqC/gsH2lrEGKhf2nt2nWJw= Received: by 10.78.165.16 with SMTP id n16mr5451862hue; Mon, 09 Oct 2006 13:25:19 -0700 (PDT) Received: by 10.78.100.13 with HTTP; Mon, 9 Oct 2006 13:25:19 -0700 (PDT) Message-ID: <38c19b540610091325h14401141jbcd61a94b9fa3c5@mail.gmail.com> Date: Mon, 9 Oct 2006 13:25:19 -0700 From: "Greg Shepherd" To: "Mark Watson" Subject: Re: [Fecframe] IETF 67 In-Reply-To: <38c19b540609251047p68e421b3n93f95ea16e902640@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <277CB7DD1E4B4C4C860484C00389C9C978540C@EXVS01.ex.dslextreme.net> <38c19b540609251047p68e421b3n93f95ea16e902640@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: fecframe@ietf.org X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Wow, no answers... no flames even. Maybe I need to be more offensive to get some discussions going. ;-) That said, where are we with agenda items for the IETF 67? As per our charter we have a milestone after this meeting for a WG approval of the reqs draft to move it up the tree. Can someone take the roll of eloquently stating the pros/cons of making streaming fit into an existing FEC BB (RMT) vs FECFrame BB defining streaming outside of RMT. Cheers, Greg On 9/25/06, Greg Shepherd wrote: > On 9/12/06, Mark Watson wrote: > > Hi Wesley, > > > > Good point. This kind of consideration would be a good addition to the > > draft. > > > > The RMT FEC Building Block does indeed provide a lot of what we need. > > The main differences are in places where the FEC BB makes assumptions > > related to the delivered data being a single 'object' rather than a > > collection of streams/packet flows. > > > > Streams/packet flows have some additional properties - such as somewhat > > different needs for timely delivery, the fact that packet sizes for > > source packets are a property of the stream, not something that the FEC > > mechanism can determine as with object delivery and the requirement to > > protect multiple streams together. > > > > Now, one approach would be to define a way to map a collection of > > streams/packet flows into an 'object' of the kind addressed in the FEC > > BB and then concatenate this mapping with what we already have in the > > FEC BB. > > > > This might be a little contrived though, so I think what we are aiming > > at is essentially a 'stream/packet flow' version of the FEC BB - reusing > > as much as possible of course. > > > > As with the FEC BB, there is an open question about exactly what > > functionality to specify in the BB and what to delegate to FEC Schemes. > > Delegation has the advantage of generality, whereas specification at the > > FEC BB has the advantage of introducing greater commonality between > > different instantiations of the whole system. > > So which direction do we take? Should this be an agenda item for the > upcoming meeting? To stay on track we should have the framework draft > ready for submission after IETF 67 so getting the discussion going now > is best. > > I agree that stuffing streaming functions into an object to make it > fit FEC BB is a bit contrived, but can it be done? What functionality > would be compromised? Would this prevent extensibiliy in streaming > functions over having an independent (though inheriting) FECFrame > spec? > > Greg > > > Regards, > > > > Mark > > > > -----Original Message----- > > From: Wesley Eddy [mailto:weddy@grc.nasa.gov] > > Sent: Tuesday, September 12, 2006 10:12 AM > > To: Greg Shepherd > > Cc: fecframe@ietf.org > > Subject: Re: [Fecframe] IETF 67 > > > > On Tue, Sep 12, 2006 at 04:37:12AM -0700, Greg Shepherd wrote: > > > Hello, > > > > > > We're coming up on IETF 67 and our next milestone of approving our > > > requirements as presented in: > > > > > > draft-ietf-fecframe-req-00 > > > > > > Since IETF 66 there has been little or no discussion on the list > > > regarding the reqs, or anything else for that matter. Heck, many other > > > IETF WG lists find plenty of non-issues to flame about but we can't > > > even find the time or interest to discuss real topics. ;-) > > > > > > So, please, read the above req draft and send your feedback here to > > > the list. Sure, we could move the draft forward with the assumption > > > that no feedback is positive feedback but that seems a bit > > > disingenuous and actually pretty boring to be honest. > > > > > > > I've read the draft. Since the RMT FEC building block is described as > > the basis for FECFRAME, I think there should be a short section on why > > the FEC building block alone isn't sufficient for FECFRAME's goals. > > Looking at the requirements, the FEC building block meets many of these > > already, so it would be valuable to discuss exactly which requirements > > require additional mechanisms. Without this kind of "gap-analysis" of > > the existing solution, the real goal of the work is unclear. > > > > Also, a minor comment, I'd prefer if the requirements were numbered in > > units of 1's rather than in 10's, but this really doesn't matter. There > > are also two requirements numbered 30 in the 00 version of the draft. > > > > -- > > Wesley M. Eddy > > Verizon Federal Network Systems > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www1.ietf.org/mailman/listinfo/fecframe > > > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Oct 09 17:10:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2OI-0001RH-0h; Mon, 09 Oct 2006 17:10:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2OG-0001QU-RE for fecframe@ietf.org; Mon, 09 Oct 2006 17:10:24 -0400 Received: from exbe04.ex.dslextreme.net ([66.51.199.86] helo=EXVS01.ex.dslextreme.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX2OG-0007nf-Aw for fecframe@ietf.org; Mon, 09 Oct 2006 17:10:24 -0400 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 Subject: RE: [Fecframe] IETF 67 Date: Mon, 9 Oct 2006 14:09:43 -0700 Message-ID: <277CB7DD1E4B4C4C860484C00389C9C98C5F60@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] IETF 67 Thread-Index: Acbr4Q8EGrs8Z9xgTbW8ycV4HmIlcwAA4nAg From: "Mark Watson" To: "Greg Shepherd" X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: fecframe@ietf.org X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Hi Greg, The main advantage that could be expected from fitting streaming into the RMT FEC BB would be that FEC Schemes already defined by RMT could be reused for streaming without modification. However, I'm not sure that would actually work, for the following reasons: Firstly, the FEC Schemes defined in RMT envisage objects with a finite size. So, to map streaming to this we would need to consider a stream as a sequence of FEC BB-style objects. We would then need to communicate the FEC Object Transmission Information for each object with that object. This could be done, but the problem is that for many FEC Schemes there would be advantages if certain pieces of FEC Object Transmission Information could be the same for every block (for example it makes sense in some cases for the Symbol Size and Block Size to be the same for every block). It's advantageous to be able to inform the receiver that these parameters won't change and also more efficient to signal them once, out-of-band, than with every block. Without streaming-specific additions to the FEC Scheme you could not specify how this "stream-level" FEC OTI was communicated to the receiver. So, you would not achieve the original aim of re-using the FEC Schemes without modification anyway. Secondly, FEC Schemes in RMT generally also include recommendations for parameter settings, which are based on single-object delivery. Although not essential it would be a good thing for people to provide recommendations for streaming cases too - which may be different for a variety of reasons. Given that we need streaming-specific modifications to FEC Schemes anyway, it seems better to me to do this cleanly. This does not mean that we lose the work done in RMT, but that we recognize that re-use of an RMT FEC Scheme for FECFRAME doesn't come for free - it requires a little work. A third reason is the question of how streaming source data is formatted into data blocks that an 'object-based' FEC Scheme could process. RMT FEC Schemes expect an object which is just a sequence of bytes. For streaming we need to build such an object out of a sequence of potentially variable-length source packets. We then have the problem that we don't just send the symbols generated by the FEC Scheme, but we may wish to send the original source packets themselves. The mapping between the source block that the RMT FEC Scheme understands and the Source Packets themselves may again be something where specification material which is both FEC-Scheme-specific and Streaming-specific is needed. This was a topic of discussion at the last meeting: The 3GPP FEC streaming framework makes this issue FEC-Scheme-independent (if that can be claimed of a spec which includes only one FEC Scheme!), whereas I had proposed last time we allow also for FEC-Scheme-specific approaches. We did not conclude on this, but I would propose that we allow FEC Schemes to specify their own approach (and of course, the Raptor FEC Scheme will use the 3GPP one to align with 3GPP's use of Raptor). Regards, Mark Watson -----Original Message----- From: Greg Shepherd [mailto:gjshep@gmail.com]=20 Sent: Monday, October 09, 2006 4:25 PM To: Mark Watson Cc: weddy@grc.nasa.gov; fecframe@ietf.org Subject: Re: [Fecframe] IETF 67 Wow, no answers... no flames even. Maybe I need to be more offensive to get some discussions going. ;-) That said, where are we with agenda items for the IETF 67? As per our charter we have a milestone after this meeting for a WG approval of the reqs draft to move it up the tree. Can someone take the roll of eloquently stating the pros/cons of making streaming fit into an existing FEC BB (RMT) vs FECFrame BB defining streaming outside of RMT. Cheers, Greg On 9/25/06, Greg Shepherd wrote: > On 9/12/06, Mark Watson wrote: > > Hi Wesley, > > > > Good point. This kind of consideration would be a good addition to the > > draft. > > > > The RMT FEC Building Block does indeed provide a lot of what we need. > > The main differences are in places where the FEC BB makes assumptions > > related to the delivered data being a single 'object' rather than a > > collection of streams/packet flows. > > > > Streams/packet flows have some additional properties - such as somewhat > > different needs for timely delivery, the fact that packet sizes for > > source packets are a property of the stream, not something that the FEC > > mechanism can determine as with object delivery and the requirement to > > protect multiple streams together. > > > > Now, one approach would be to define a way to map a collection of > > streams/packet flows into an 'object' of the kind addressed in the FEC > > BB and then concatenate this mapping with what we already have in the > > FEC BB. > > > > This might be a little contrived though, so I think what we are aiming > > at is essentially a 'stream/packet flow' version of the FEC BB - reusing > > as much as possible of course. > > > > As with the FEC BB, there is an open question about exactly what > > functionality to specify in the BB and what to delegate to FEC Schemes. > > Delegation has the advantage of generality, whereas specification at the > > FEC BB has the advantage of introducing greater commonality between > > different instantiations of the whole system. > > So which direction do we take? Should this be an agenda item for the > upcoming meeting? To stay on track we should have the framework draft > ready for submission after IETF 67 so getting the discussion going now > is best. > > I agree that stuffing streaming functions into an object to make it > fit FEC BB is a bit contrived, but can it be done? What functionality > would be compromised? Would this prevent extensibiliy in streaming > functions over having an independent (though inheriting) FECFrame > spec? > > Greg > > > Regards, > > > > Mark > > > > -----Original Message----- > > From: Wesley Eddy [mailto:weddy@grc.nasa.gov] > > Sent: Tuesday, September 12, 2006 10:12 AM > > To: Greg Shepherd > > Cc: fecframe@ietf.org > > Subject: Re: [Fecframe] IETF 67 > > > > On Tue, Sep 12, 2006 at 04:37:12AM -0700, Greg Shepherd wrote: > > > Hello, > > > > > > We're coming up on IETF 67 and our next milestone of approving our > > > requirements as presented in: > > > > > > draft-ietf-fecframe-req-00 > > > > > > Since IETF 66 there has been little or no discussion on the list > > > regarding the reqs, or anything else for that matter. Heck, many other > > > IETF WG lists find plenty of non-issues to flame about but we can't > > > even find the time or interest to discuss real topics. ;-) > > > > > > So, please, read the above req draft and send your feedback here to > > > the list. Sure, we could move the draft forward with the assumption > > > that no feedback is positive feedback but that seems a bit > > > disingenuous and actually pretty boring to be honest. > > > > > > > I've read the draft. Since the RMT FEC building block is described as > > the basis for FECFRAME, I think there should be a short section on why > > the FEC building block alone isn't sufficient for FECFRAME's goals. > > Looking at the requirements, the FEC building block meets many of these > > already, so it would be valuable to discuss exactly which requirements > > require additional mechanisms. Without this kind of "gap-analysis" of > > the existing solution, the real goal of the work is unclear. > > > > Also, a minor comment, I'd prefer if the requirements were numbered in > > units of 1's rather than in 10's, but this really doesn't matter. There > > are also two requirements numbered 30 in the 00 version of the draft. > > > > -- > > Wesley M. Eddy > > Verizon Federal Network Systems > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www1.ietf.org/mailman/listinfo/fecframe > > > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Oct 10 12:28:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKSo-0005Lf-50; Tue, 10 Oct 2006 12:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKSm-0005La-Ul for fecframe@ietf.org; Tue, 10 Oct 2006 12:28:16 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKSm-0002uT-Jy for fecframe@ietf.org; Tue, 10 Oct 2006 12:28:16 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5251193; Tue, 10 Oct 2006 12:28:15 -0400 In-Reply-To: <047E3BFF-6FD0-460A-9262-976971C97076@multicasttech.com> References: <277CB7DD1E4B4C4C860484C00389C9C978540C@EXVS01.ex.dslextreme.net> <38c19b540609251047p68e421b3n93f95ea16e902640@mail.gmail.com> <38c19b540610091325h14401141jbcd61a94b9fa3c5@mail.gmail.com> <047E3BFF-6FD0-460A-9262-976971C97076@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C91CBF5-22AD-4900-BED6-26E62AC65DA1@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [Fecframe] IETF 67 Date: Tue, 10 Oct 2006 12:27:24 -0400 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: fecframe@ietf.org X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Sorry, don't know how this got out like the below. Here is the complete version : I met with Mark Watson in Broomfield, Colorado, last week. We discussed the requirements document, draft-ietf-fecframe-req-00 , which I think still needs a careful review. I volunteered to provide that review. My feeling is that we are probably ready to move to the next step, and Mark volunteered to take the lead in writing the problem statement. If anyone wants to participate in this, please contact us or Mark directly. I would like to get consensus on the requirements document by San Diego, and hopefully we will also have a first look at the problem statement. We need to set up an agenda for San Diego, so if anyone has suggestions for agenda items, please send them to us. Regards Marshall On Oct 9, 2006, at 4:44 PM, Marshall Eubanks wrote: > I met with Mark Watson > On Oct 9, 2006, at 4:25 PM, Greg Shepherd wrote: > >> Wow, no answers... no flames even. Maybe I need to be more offensive >> to get some discussions going. ;-) >> >> That said, where are we with agenda items for the IETF 67? >> >> As per our charter we have a milestone after this meeting for a WG >> approval of the reqs draft to move it up the tree. >> >> Can someone take the roll of eloquently stating the pros/cons of >> making streaming fit into an existing FEC BB (RMT) vs FECFrame BB >> defining streaming outside of RMT. >> >> Cheers, >> Greg >> >> On 9/25/06, Greg Shepherd wrote: >>> On 9/12/06, Mark Watson wrote: >>> > Hi Wesley, >>> > >>> > Good point. This kind of consideration would be a good addition >>> to the >>> > draft. >>> > >>> > The RMT FEC Building Block does indeed provide a lot of what we >>> need. >>> > The main differences are in places where the FEC BB makes >>> assumptions >>> > related to the delivered data being a single 'object' rather >>> than a >>> > collection of streams/packet flows. >>> > >>> > Streams/packet flows have some additional properties - such as >>> somewhat >>> > different needs for timely delivery, the fact that packet sizes >>> for >>> > source packets are a property of the stream, not something that >>> the FEC >>> > mechanism can determine as with object delivery and the >>> requirement to >>> > protect multiple streams together. >>> > >>> > Now, one approach would be to define a way to map a collection of >>> > streams/packet flows into an 'object' of the kind addressed in >>> the FEC >>> > BB and then concatenate this mapping with what we already have >>> in the >>> > FEC BB. >>> > >>> > This might be a little contrived though, so I think what we are >>> aiming >>> > at is essentially a 'stream/packet flow' version of the FEC BB >>> - reusing >>> > as much as possible of course. >>> > >>> > As with the FEC BB, there is an open question about exactly what >>> > functionality to specify in the BB and what to delegate to FEC >>> Schemes. >>> > Delegation has the advantage of generality, whereas >>> specification at the >>> > FEC BB has the advantage of introducing greater commonality >>> between >>> > different instantiations of the whole system. >>> >>> So which direction do we take? Should this be an agenda item for the >>> upcoming meeting? To stay on track we should have the framework >>> draft >>> ready for submission after IETF 67 so getting the discussion >>> going now >>> is best. >>> >>> I agree that stuffing streaming functions into an object to make it >>> fit FEC BB is a bit contrived, but can it be done? What >>> functionality >>> would be compromised? Would this prevent extensibiliy in streaming >>> functions over having an independent (though inheriting) FECFrame >>> spec? >>> >>> Greg >>> >>> > Regards, >>> > >>> > Mark >>> > >>> > -----Original Message----- >>> > From: Wesley Eddy [mailto:weddy@grc.nasa.gov] >>> > Sent: Tuesday, September 12, 2006 10:12 AM >>> > To: Greg Shepherd >>> > Cc: fecframe@ietf.org >>> > Subject: Re: [Fecframe] IETF 67 >>> > >>> > On Tue, Sep 12, 2006 at 04:37:12AM -0700, Greg Shepherd wrote: >>> > > Hello, >>> > > >>> > > We're coming up on IETF 67 and our next milestone of >>> approving our >>> > > requirements as presented in: >>> > > >>> > > draft-ietf-fecframe-req-00 >>> > > >>> > > Since IETF 66 there has been little or no discussion on the list >>> > > regarding the reqs, or anything else for that matter. Heck, >>> many other >>> > > IETF WG lists find plenty of non-issues to flame about but we >>> can't >>> > > even find the time or interest to discuss real topics. ;-) >>> > > >>> > > So, please, read the above req draft and send your feedback >>> here to >>> > > the list. Sure, we could move the draft forward with the >>> assumption >>> > > that no feedback is positive feedback but that seems a bit >>> > > disingenuous and actually pretty boring to be honest. >>> > > >>> > >>> > I've read the draft. Since the RMT FEC building block is >>> described as >>> > the basis for FECFRAME, I think there should be a short section >>> on why >>> > the FEC building block alone isn't sufficient for FECFRAME's >>> goals. >>> > Looking at the requirements, the FEC building block meets many >>> of these >>> > already, so it would be valuable to discuss exactly which >>> requirements >>> > require additional mechanisms. Without this kind of "gap- >>> analysis" of >>> > the existing solution, the real goal of the work is unclear. >>> > >>> > Also, a minor comment, I'd prefer if the requirements were >>> numbered in >>> > units of 1's rather than in 10's, but this really doesn't >>> matter. There >>> > are also two requirements numbered 30 in the 00 version of the >>> draft. >>> > >>> > -- >>> > Wesley M. Eddy >>> > Verizon Federal Network Systems >>> > >>> > _______________________________________________ >>> > Fecframe mailing list >>> > Fecframe@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/fecframe >>> > >>> >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www1.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Oct 10 22:35:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXTw1-0004uQ-QW; Tue, 10 Oct 2006 22:35:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXTvz-0004uD-0r for fecframe@ietf.org; Tue, 10 Oct 2006 22:35:03 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXTvx-0000yH-QQ for fecframe@ietf.org; Tue, 10 Oct 2006 22:35:03 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5262316 for fecframe@ietf.org; Tue, 10 Oct 2006 22:34:55 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Date: Tue, 10 Oct 2006 22:34:07 -0400 To: fecframe@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Fecframe] Fwd: 67th IETF - Scheduling Cutoff X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Note that FecFrame is currently scheduled for WEDNESDAY, November 8, 2006 1510-1610 Afternoon Session II INT mip4 Mobility for IPv4 WG RAI mediactl Media Server Control BOF SEC ltans Long-Term Archive and Notary Services WG TSV fecframe FEC Framework WG If there is any problem, please send the details to Greg and myself ASAP. Please be specific as to the conflict (it would help to provide drafts being discussed, their relevance to FECFRAME, etc.). Regards Marshall Begin forwarded message: > From: IETF Agenda > Date: October 10, 2006 8:37:07 PM EDT > To: Working Group Chairs > Cc: irsg@isi.edu, bofchairs!@ietf.org > Subject: 67th IETF - Scheduling Cutoff > > The preliminary agenda can be found at: > http://www.ietf.org/meetings/agenda_67.txt > > October 11, Wednesday - Cutoff date for requests to reschedule Working > Group and BOF meetings 09:00 ET (13:00 UTC/GMT) > > Please send messages to agenda@ietf.org. > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Oct 20 13:27:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gay9b-0006sc-Nm; Fri, 20 Oct 2006 13:27:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gay7V-0005mf-Av for fecframe@ietf.org; Fri, 20 Oct 2006 13:25:21 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaxwx-0004kW-8O for fecframe@ietf.org; Fri, 20 Oct 2006 13:14:27 -0400 Received: by ug-out-1314.google.com with SMTP id z34so680468ugc for ; Fri, 20 Oct 2006 10:14:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c6Fd6f2sRBKtBs5obizDWORE3OLprkzlPByFc9NFczrX1lKb0r89wDRJAU0W/J8XgRIvwj//YOkFj5wx+aTUpuMtJGMw5viqmp9O2BnxK39XAF+LdTgTtRrQReiA/ydIxv9VCZNFJvzeSfWeuXYb7TkVNE7I/ejmlrSx35/vgd8= Received: by 10.78.131.8 with SMTP id e8mr2319938hud; Fri, 20 Oct 2006 10:14:25 -0700 (PDT) Received: by 10.78.100.13 with HTTP; Fri, 20 Oct 2006 10:14:25 -0700 (PDT) Message-ID: <38c19b540610201014n5ab79813q18453bf9894304fc@mail.gmail.com> Date: Fri, 20 Oct 2006 10:14:25 -0700 From: "Greg Shepherd" To: "Marshall Eubanks" Subject: Re: [Fecframe] IETF 67 In-Reply-To: <7C91CBF5-22AD-4900-BED6-26E62AC65DA1@multicasttech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <277CB7DD1E4B4C4C860484C00389C9C978540C@EXVS01.ex.dslextreme.net> <38c19b540609251047p68e421b3n93f95ea16e902640@mail.gmail.com> <38c19b540610091325h14401141jbcd61a94b9fa3c5@mail.gmail.com> <047E3BFF-6FD0-460A-9262-976971C97076@multicasttech.com> <7C91CBF5-22AD-4900-BED6-26E62AC65DA1@multicasttech.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: fecframe@ietf.org X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Plea for Agenda Items So far we have Mark presenting the "final" version of the reqs doc - which incorporates input from the last WG meeting. And possibly Mark presenting the problem statement. A possible 3rd agenda item could be a proposal to change the WB name to "Mark". ;-) Anything else? Thanks, Greg On 10/10/06, Marshall Eubanks wrote: > Sorry, don't know how this got out like the below. Here is the > complete version : > > I met with Mark Watson in Broomfield, Colorado, last week. We > discussed the > requirements document, > draft-ietf-fecframe-req-00 , which I think still needs > a careful review. I volunteered to provide that review. > > My feeling is that we are probably ready to move to the next step, > and Mark volunteered to > take the lead in writing the problem statement. > If anyone wants to participate in this, please contact us or Mark > directly. > > I would like to get consensus on the requirements document by San > Diego, and hopefully > we will also have a first look at the problem statement. > > We need to set up an agenda for San Diego, so if anyone has > suggestions for agenda items, please send them to us. > > Regards > Marshall > > On Oct 9, 2006, at 4:44 PM, Marshall Eubanks wrote: > > > I met with Mark Watson > > On Oct 9, 2006, at 4:25 PM, Greg Shepherd wrote: > > > >> Wow, no answers... no flames even. Maybe I need to be more offensive > >> to get some discussions going. ;-) > >> > >> That said, where are we with agenda items for the IETF 67? > >> > >> As per our charter we have a milestone after this meeting for a WG > >> approval of the reqs draft to move it up the tree. > >> > >> Can someone take the roll of eloquently stating the pros/cons of > >> making streaming fit into an existing FEC BB (RMT) vs FECFrame BB > >> defining streaming outside of RMT. > >> > >> Cheers, > >> Greg > >> > >> On 9/25/06, Greg Shepherd wrote: > >>> On 9/12/06, Mark Watson wrote: > >>> > Hi Wesley, > >>> > > >>> > Good point. This kind of consideration would be a good addition > >>> to the > >>> > draft. > >>> > > >>> > The RMT FEC Building Block does indeed provide a lot of what we > >>> need. > >>> > The main differences are in places where the FEC BB makes > >>> assumptions > >>> > related to the delivered data being a single 'object' rather > >>> than a > >>> > collection of streams/packet flows. > >>> > > >>> > Streams/packet flows have some additional properties - such as > >>> somewhat > >>> > different needs for timely delivery, the fact that packet sizes > >>> for > >>> > source packets are a property of the stream, not something that > >>> the FEC > >>> > mechanism can determine as with object delivery and the > >>> requirement to > >>> > protect multiple streams together. > >>> > > >>> > Now, one approach would be to define a way to map a collection of > >>> > streams/packet flows into an 'object' of the kind addressed in > >>> the FEC > >>> > BB and then concatenate this mapping with what we already have > >>> in the > >>> > FEC BB. > >>> > > >>> > This might be a little contrived though, so I think what we are > >>> aiming > >>> > at is essentially a 'stream/packet flow' version of the FEC BB > >>> - reusing > >>> > as much as possible of course. > >>> > > >>> > As with the FEC BB, there is an open question about exactly what > >>> > functionality to specify in the BB and what to delegate to FEC > >>> Schemes. > >>> > Delegation has the advantage of generality, whereas > >>> specification at the > >>> > FEC BB has the advantage of introducing greater commonality > >>> between > >>> > different instantiations of the whole system. > >>> > >>> So which direction do we take? Should this be an agenda item for the > >>> upcoming meeting? To stay on track we should have the framework > >>> draft > >>> ready for submission after IETF 67 so getting the discussion > >>> going now > >>> is best. > >>> > >>> I agree that stuffing streaming functions into an object to make it > >>> fit FEC BB is a bit contrived, but can it be done? What > >>> functionality > >>> would be compromised? Would this prevent extensibiliy in streaming > >>> functions over having an independent (though inheriting) FECFrame > >>> spec? > >>> > >>> Greg > >>> > >>> > Regards, > >>> > > >>> > Mark > >>> > > >>> > -----Original Message----- > >>> > From: Wesley Eddy [mailto:weddy@grc.nasa.gov] > >>> > Sent: Tuesday, September 12, 2006 10:12 AM > >>> > To: Greg Shepherd > >>> > Cc: fecframe@ietf.org > >>> > Subject: Re: [Fecframe] IETF 67 > >>> > > >>> > On Tue, Sep 12, 2006 at 04:37:12AM -0700, Greg Shepherd wrote: > >>> > > Hello, > >>> > > > >>> > > We're coming up on IETF 67 and our next milestone of > >>> approving our > >>> > > requirements as presented in: > >>> > > > >>> > > draft-ietf-fecframe-req-00 > >>> > > > >>> > > Since IETF 66 there has been little or no discussion on the list > >>> > > regarding the reqs, or anything else for that matter. Heck, > >>> many other > >>> > > IETF WG lists find plenty of non-issues to flame about but we > >>> can't > >>> > > even find the time or interest to discuss real topics. ;-) > >>> > > > >>> > > So, please, read the above req draft and send your feedback > >>> here to > >>> > > the list. Sure, we could move the draft forward with the > >>> assumption > >>> > > that no feedback is positive feedback but that seems a bit > >>> > > disingenuous and actually pretty boring to be honest. > >>> > > > >>> > > >>> > I've read the draft. Since the RMT FEC building block is > >>> described as > >>> > the basis for FECFRAME, I think there should be a short section > >>> on why > >>> > the FEC building block alone isn't sufficient for FECFRAME's > >>> goals. > >>> > Looking at the requirements, the FEC building block meets many > >>> of these > >>> > already, so it would be valuable to discuss exactly which > >>> requirements > >>> > require additional mechanisms. Without this kind of "gap- > >>> analysis" of > >>> > the existing solution, the real goal of the work is unclear. > >>> > > >>> > Also, a minor comment, I'd prefer if the requirements were > >>> numbered in > >>> > units of 1's rather than in 10's, but this really doesn't > >>> matter. There > >>> > are also two requirements numbered 30 in the 00 version of the > >>> draft. > >>> > > >>> > -- > >>> > Wesley M. Eddy > >>> > Verizon Federal Network Systems > >>> > > >>> > _______________________________________________ > >>> > Fecframe mailing list > >>> > Fecframe@ietf.org > >>> > https://www1.ietf.org/mailman/listinfo/fecframe > >>> > > >>> > >> > >> _______________________________________________ > >> Fecframe mailing list > >> Fecframe@ietf.org > >> https://www1.ietf.org/mailman/listinfo/fecframe > > > > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Oct 20 15:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gazgb-0007iG-KT; Fri, 20 Oct 2006 15:05:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gazga-0007hu-Hy for fecframe@ietf.org; Fri, 20 Oct 2006 15:05:40 -0400 Received: from exbe04.ex.dslextreme.net ([66.51.199.86] helo=EXVS01.ex.dslextreme.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GazgT-0001F0-3o for fecframe@ietf.org; Fri, 20 Oct 2006 15:05:40 -0400 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 Subject: RE: [Fecframe] IETF 67 Date: Fri, 20 Oct 2006 12:04:48 -0700 Message-ID: <277CB7DD1E4B4C4C860484C00389C9C99A5DE6@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] IETF 67 Thread-Index: Acb0bDc1Q03VaJlHQ/O39l49l4ey0QACvGng From: "Mark Watson" To: "Greg Shepherd" , "Marshall Eubanks" X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: fecframe@ietf.org X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Greg, Marshall, I submitted a first draft proposal for the FEC Framework itself as: draft-watson-fecframe-framework-00 (http://www.ietf.org/internet-drafts/draft-watson-fecframe-framework-00. txt) So, I could make a presentation on this. This is the document that I spoke to Marshall about, but perhaps there has been some mis-communication, since he refers below to a "problem statement" - do we need a more detailed problem statement than the Charter itself and the requirements document ? Btw, I submitted the proposal above in part to try and encourage more comments as well as to progress the work. I agree that the requirements need a bit more review and we can progress that in parallel with the solution. Renaming the working group and giving me total dictatorial power would be just fine ... but perhaps that is not allowed under IETF rules ? ...Mark -----Original Message----- From: Greg Shepherd [mailto:gjshep@gmail.com]=20 Sent: Friday, October 20, 2006 10:14 AM To: Marshall Eubanks Cc: Mark Watson; fecframe@ietf.org Subject: Re: [Fecframe] IETF 67 Plea for Agenda Items So far we have Mark presenting the "final" version of the reqs doc - which incorporates input from the last WG meeting. And possibly Mark presenting the problem statement. A possible 3rd agenda item could be a proposal to change the WB name to "Mark". ;-) Anything else? Thanks, Greg On 10/10/06, Marshall Eubanks wrote: > Sorry, don't know how this got out like the below. Here is the > complete version : > > I met with Mark Watson in Broomfield, Colorado, last week. We > discussed the > requirements document, > draft-ietf-fecframe-req-00 , which I think still needs > a careful review. I volunteered to provide that review. > > My feeling is that we are probably ready to move to the next step, > and Mark volunteered to > take the lead in writing the problem statement. > If anyone wants to participate in this, please contact us or Mark > directly. > > I would like to get consensus on the requirements document by San > Diego, and hopefully > we will also have a first look at the problem statement. > > We need to set up an agenda for San Diego, so if anyone has > suggestions for agenda items, please send them to us. > > Regards > Marshall > > On Oct 9, 2006, at 4:44 PM, Marshall Eubanks wrote: > > > I met with Mark Watson > > On Oct 9, 2006, at 4:25 PM, Greg Shepherd wrote: > > > >> Wow, no answers... no flames even. Maybe I need to be more offensive > >> to get some discussions going. ;-) > >> > >> That said, where are we with agenda items for the IETF 67? > >> > >> As per our charter we have a milestone after this meeting for a WG > >> approval of the reqs draft to move it up the tree. > >> > >> Can someone take the roll of eloquently stating the pros/cons of > >> making streaming fit into an existing FEC BB (RMT) vs FECFrame BB > >> defining streaming outside of RMT. > >> > >> Cheers, > >> Greg > >> > >> On 9/25/06, Greg Shepherd wrote: > >>> On 9/12/06, Mark Watson wrote: > >>> > Hi Wesley, > >>> > > >>> > Good point. This kind of consideration would be a good addition > >>> to the > >>> > draft. > >>> > > >>> > The RMT FEC Building Block does indeed provide a lot of what we > >>> need. > >>> > The main differences are in places where the FEC BB makes > >>> assumptions > >>> > related to the delivered data being a single 'object' rather > >>> than a > >>> > collection of streams/packet flows. > >>> > > >>> > Streams/packet flows have some additional properties - such as > >>> somewhat > >>> > different needs for timely delivery, the fact that packet sizes > >>> for > >>> > source packets are a property of the stream, not something that > >>> the FEC > >>> > mechanism can determine as with object delivery and the > >>> requirement to > >>> > protect multiple streams together. > >>> > > >>> > Now, one approach would be to define a way to map a collection of > >>> > streams/packet flows into an 'object' of the kind addressed in > >>> the FEC > >>> > BB and then concatenate this mapping with what we already have > >>> in the > >>> > FEC BB. > >>> > > >>> > This might be a little contrived though, so I think what we are > >>> aiming > >>> > at is essentially a 'stream/packet flow' version of the FEC BB > >>> - reusing > >>> > as much as possible of course. > >>> > > >>> > As with the FEC BB, there is an open question about exactly what > >>> > functionality to specify in the BB and what to delegate to FEC > >>> Schemes. > >>> > Delegation has the advantage of generality, whereas > >>> specification at the > >>> > FEC BB has the advantage of introducing greater commonality > >>> between > >>> > different instantiations of the whole system. > >>> > >>> So which direction do we take? Should this be an agenda item for the > >>> upcoming meeting? To stay on track we should have the framework > >>> draft > >>> ready for submission after IETF 67 so getting the discussion > >>> going now > >>> is best. > >>> > >>> I agree that stuffing streaming functions into an object to make it > >>> fit FEC BB is a bit contrived, but can it be done? What > >>> functionality > >>> would be compromised? Would this prevent extensibiliy in streaming > >>> functions over having an independent (though inheriting) FECFrame > >>> spec? > >>> > >>> Greg > >>> > >>> > Regards, > >>> > > >>> > Mark > >>> > > >>> > -----Original Message----- > >>> > From: Wesley Eddy [mailto:weddy@grc.nasa.gov] > >>> > Sent: Tuesday, September 12, 2006 10:12 AM > >>> > To: Greg Shepherd > >>> > Cc: fecframe@ietf.org > >>> > Subject: Re: [Fecframe] IETF 67 > >>> > > >>> > On Tue, Sep 12, 2006 at 04:37:12AM -0700, Greg Shepherd wrote: > >>> > > Hello, > >>> > > > >>> > > We're coming up on IETF 67 and our next milestone of > >>> approving our > >>> > > requirements as presented in: > >>> > > > >>> > > draft-ietf-fecframe-req-00 > >>> > > > >>> > > Since IETF 66 there has been little or no discussion on the list > >>> > > regarding the reqs, or anything else for that matter. Heck, > >>> many other > >>> > > IETF WG lists find plenty of non-issues to flame about but we > >>> can't > >>> > > even find the time or interest to discuss real topics. ;-) > >>> > > > >>> > > So, please, read the above req draft and send your feedback > >>> here to > >>> > > the list. Sure, we could move the draft forward with the > >>> assumption > >>> > > that no feedback is positive feedback but that seems a bit > >>> > > disingenuous and actually pretty boring to be honest. > >>> > > > >>> > > >>> > I've read the draft. Since the RMT FEC building block is > >>> described as > >>> > the basis for FECFRAME, I think there should be a short section > >>> on why > >>> > the FEC building block alone isn't sufficient for FECFRAME's > >>> goals. > >>> > Looking at the requirements, the FEC building block meets many > >>> of these > >>> > already, so it would be valuable to discuss exactly which > >>> requirements > >>> > require additional mechanisms. Without this kind of "gap- > >>> analysis" of > >>> > the existing solution, the real goal of the work is unclear. > >>> > > >>> > Also, a minor comment, I'd prefer if the requirements were > >>> numbered in > >>> > units of 1's rather than in 10's, but this really doesn't > >>> matter. There > >>> > are also two requirements numbered 30 in the 00 version of the > >>> draft. > >>> > > >>> > -- > >>> > Wesley M. Eddy > >>> > Verizon Federal Network Systems > >>> > > >>> > _______________________________________________ > >>> > Fecframe mailing list > >>> > Fecframe@ietf.org > >>> > https://www1.ietf.org/mailman/listinfo/fecframe > >>> > > >>> > >> > >> _______________________________________________ > >> Fecframe mailing list > >> Fecframe@ietf.org > >> https://www1.ietf.org/mailman/listinfo/fecframe > > > > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Oct 20 19:38:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb3wy-0005NT-5O; Fri, 20 Oct 2006 19:38:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb3wx-0005NO-9Y for fecframe@ietf.org; Fri, 20 Oct 2006 19:38:51 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb3ww-0005mc-TN for fecframe@ietf.org; Fri, 20 Oct 2006 19:38:51 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5417118; Fri, 20 Oct 2006 19:38:50 -0400 In-Reply-To: <277CB7DD1E4B4C4C860484C00389C9C99A5DE6@EXVS01.ex.dslextreme.net> References: <277CB7DD1E4B4C4C860484C00389C9C99A5DE6@EXVS01.ex.dslextreme.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2DDB2983-8B25-4F1B-8750-3BA336799152@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [Fecframe] IETF 67 Date: Fri, 20 Oct 2006 19:38:05 -0400 To: "Mark Watson" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: fecframe@ietf.org X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Dear Mark; On Oct 20, 2006, at 3:04 PM, Mark Watson wrote: > Greg, Marshall, > > I submitted a first draft proposal for the FEC Framework itself as: > > draft-watson-fecframe-framework-00 > > (http://www.ietf.org/internet-drafts/draft-watson-fecframe- > framework-00. > txt) > > So, I could make a presentation on this. > > This is the document that I spoke to Marshall about, but perhaps there > has been some mis-communication, since he refers below to a "problem > statement" - do we need a more detailed problem statement than the > Charter itself and the requirements document ? > No, I must have heard something wrong or been confused - my notes from our drive to the airport mention the problem statement but the above is the clearly the document we were talking about. > Btw, I submitted the proposal above in part to try and encourage more > comments as well as to progress the work. I agree that the > requirements > need a bit more review and we can progress that in parallel with the > solution. > I would agree. Is there anyone else with agenda items ? > Renaming the working group and giving me total dictatorial power would > be just fine ... but perhaps that is not allowed under IETF rules ? > > ...Mark Marshall > > -----Original Message----- > From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Friday, October 20, 2006 10:14 AM > To: Marshall Eubanks > Cc: Mark Watson; fecframe@ietf.org > Subject: Re: [Fecframe] IETF 67 > > Plea for Agenda Items > > So far we have Mark presenting the "final" version of the reqs doc - > which incorporates input from the last WG meeting. > > And possibly Mark presenting the problem statement. > > A possible 3rd agenda item could be a proposal to change the WB name > to "Mark". ;-) > > Anything else? > > Thanks, > Greg > > On 10/10/06, Marshall Eubanks wrote: >> Sorry, don't know how this got out like the below. Here is the >> complete version : >> >> I met with Mark Watson in Broomfield, Colorado, last week. We >> discussed the >> requirements document, >> draft-ietf-fecframe-req-00 , which I think still needs >> a careful review. I volunteered to provide that review. >> >> My feeling is that we are probably ready to move to the next step, >> and Mark volunteered to >> take the lead in writing the problem statement. >> If anyone wants to participate in this, please contact us or Mark >> directly. >> >> I would like to get consensus on the requirements document by San >> Diego, and hopefully >> we will also have a first look at the problem statement. >> >> We need to set up an agenda for San Diego, so if anyone has >> suggestions for agenda items, please send them to us. >> >> Regards >> Marshall >> >> On Oct 9, 2006, at 4:44 PM, Marshall Eubanks wrote: >> >>> I met with Mark Watson >>> On Oct 9, 2006, at 4:25 PM, Greg Shepherd wrote: >>> >>>> Wow, no answers... no flames even. Maybe I need to be more > offensive >>>> to get some discussions going. ;-) >>>> >>>> That said, where are we with agenda items for the IETF 67? >>>> >>>> As per our charter we have a milestone after this meeting for a WG >>>> approval of the reqs draft to move it up the tree. >>>> >>>> Can someone take the roll of eloquently stating the pros/cons of >>>> making streaming fit into an existing FEC BB (RMT) vs FECFrame BB >>>> defining streaming outside of RMT. >>>> >>>> Cheers, >>>> Greg >>>> >>>> On 9/25/06, Greg Shepherd wrote: >>>>> On 9/12/06, Mark Watson wrote: >>>>>> Hi Wesley, >>>>>> >>>>>> Good point. This kind of consideration would be a good addition >>>>> to the >>>>>> draft. >>>>>> >>>>>> The RMT FEC Building Block does indeed provide a lot of what we >>>>> need. >>>>>> The main differences are in places where the FEC BB makes >>>>> assumptions >>>>>> related to the delivered data being a single 'object' rather >>>>> than a >>>>>> collection of streams/packet flows. >>>>>> >>>>>> Streams/packet flows have some additional properties - such as >>>>> somewhat >>>>>> different needs for timely delivery, the fact that packet sizes >>>>> for >>>>>> source packets are a property of the stream, not something that >>>>> the FEC >>>>>> mechanism can determine as with object delivery and the >>>>> requirement to >>>>>> protect multiple streams together. >>>>>> >>>>>> Now, one approach would be to define a way to map a collection > of >>>>>> streams/packet flows into an 'object' of the kind addressed in >>>>> the FEC >>>>>> BB and then concatenate this mapping with what we already have >>>>> in the >>>>>> FEC BB. >>>>>> >>>>>> This might be a little contrived though, so I think what we are >>>>> aiming >>>>>> at is essentially a 'stream/packet flow' version of the FEC BB >>>>> - reusing >>>>>> as much as possible of course. >>>>>> >>>>>> As with the FEC BB, there is an open question about exactly what >>>>>> functionality to specify in the BB and what to delegate to FEC >>>>> Schemes. >>>>>> Delegation has the advantage of generality, whereas >>>>> specification at the >>>>>> FEC BB has the advantage of introducing greater commonality >>>>> between >>>>>> different instantiations of the whole system. >>>>> >>>>> So which direction do we take? Should this be an agenda item for > the >>>>> upcoming meeting? To stay on track we should have the framework >>>>> draft >>>>> ready for submission after IETF 67 so getting the discussion >>>>> going now >>>>> is best. >>>>> >>>>> I agree that stuffing streaming functions into an object to make > it >>>>> fit FEC BB is a bit contrived, but can it be done? What >>>>> functionality >>>>> would be compromised? Would this prevent extensibiliy in streaming >>>>> functions over having an independent (though inheriting) FECFrame >>>>> spec? >>>>> >>>>> Greg >>>>> >>>>>> Regards, >>>>>> >>>>>> Mark >>>>>> >>>>>> -----Original Message----- >>>>>> From: Wesley Eddy [mailto:weddy@grc.nasa.gov] >>>>>> Sent: Tuesday, September 12, 2006 10:12 AM >>>>>> To: Greg Shepherd >>>>>> Cc: fecframe@ietf.org >>>>>> Subject: Re: [Fecframe] IETF 67 >>>>>> >>>>>> On Tue, Sep 12, 2006 at 04:37:12AM -0700, Greg Shepherd wrote: >>>>>>> Hello, >>>>>>> >>>>>>> We're coming up on IETF 67 and our next milestone of >>>>> approving our >>>>>>> requirements as presented in: >>>>>>> >>>>>>> draft-ietf-fecframe-req-00 >>>>>>> >>>>>>> Since IETF 66 there has been little or no discussion on the > list >>>>>>> regarding the reqs, or anything else for that matter. Heck, >>>>> many other >>>>>>> IETF WG lists find plenty of non-issues to flame about but we >>>>> can't >>>>>>> even find the time or interest to discuss real topics. ;-) >>>>>>> >>>>>>> So, please, read the above req draft and send your feedback >>>>> here to >>>>>>> the list. Sure, we could move the draft forward with the >>>>> assumption >>>>>>> that no feedback is positive feedback but that seems a bit >>>>>>> disingenuous and actually pretty boring to be honest. >>>>>>> >>>>>> >>>>>> I've read the draft. Since the RMT FEC building block is >>>>> described as >>>>>> the basis for FECFRAME, I think there should be a short section >>>>> on why >>>>>> the FEC building block alone isn't sufficient for FECFRAME's >>>>> goals. >>>>>> Looking at the requirements, the FEC building block meets many >>>>> of these >>>>>> already, so it would be valuable to discuss exactly which >>>>> requirements >>>>>> require additional mechanisms. Without this kind of "gap- >>>>> analysis" of >>>>>> the existing solution, the real goal of the work is unclear. >>>>>> >>>>>> Also, a minor comment, I'd prefer if the requirements were >>>>> numbered in >>>>>> units of 1's rather than in 10's, but this really doesn't >>>>> matter. There >>>>>> are also two requirements numbered 30 in the 00 version of the >>>>> draft. >>>>>> >>>>>> -- >>>>>> Wesley M. Eddy >>>>>> Verizon Federal Network Systems >>>>>> >>>>>> _______________________________________________ >>>>>> Fecframe mailing list >>>>>> Fecframe@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/fecframe >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/fecframe >>> >> >> _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Wed Oct 25 23:23:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcvpi-00068t-UL; Wed, 25 Oct 2006 23:23:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcvY2-00012v-Ba for fecframe@ietf.org; Wed, 25 Oct 2006 23:04:50 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcvXy-0000W3-VB for fecframe@ietf.org; Wed, 25 Oct 2006 23:04:50 -0400 Received: by nf-out-0910.google.com with SMTP id n15so820554nfc for ; Wed, 25 Oct 2006 20:04:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=uVsmPLoLAKvLjlvEvSzLhYs4BE+1PoJthnTVkR5WCrS1x5JqZYoSFhCCifKzSftGmvftH/MOTdej91e34gpuMFpX+aqUY0VYroSD/JvP8QXAuN78rh08Vvfm1VMHsmrjWSdQlA6D3LZUyULZePPU9J0+G/vbNpOXg8uW7uQC0xA= Received: by 10.48.14.4 with SMTP id 4mr4594216nfn; Wed, 25 Oct 2006 20:04:45 -0700 (PDT) Received: by 10.48.163.20 with HTTP; Wed, 25 Oct 2006 20:04:45 -0700 (PDT) Message-ID: Date: Thu, 26 Oct 2006 11:04:45 +0800 From: "qin hao" To: fecframe@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: a7b2beb4201a28ad62fa635ed5248c27 X-Mailman-Approved-At: Wed, 25 Oct 2006 23:23:04 -0400 Subject: [Fecframe] one new document to be discussed X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0805670028==" Errors-To: fecframe-bounces@ietf.org --===============0805670028== Content-Type: multipart/alternative; boundary="----=_Part_60855_12517659.1161831885322" ------=_Part_60855_12517659.1161831885322 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear members, There is one document we want to be discussed. It is not an official document, we will submit it officially as soon as the IETF allows new submissions. The document presents a generic RTP payload format for guaranteeing QoS of video communication with FEC technique. Request you kindly provide the feedback. Best regards, FECFrame B. Song Internet-Draft H. Qin Expires: May 5, 2007 Xidian Univ. Nov 2006 Generic RTP Payload Format guaranteeing QoS of Video communication draft-bsong-fecframe-gfec-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 5, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document presents a new generic RTP payload format for guaranteeing QoS of video communication, and describes a generic scheme to packetize video stream for transport using the presented RTP payload format. Forward erasure correction and interleaving are used in the scheme to reduce the impact of the packet losses. Video stream may be unequally FEC protected with different strength such that the QoS of video communication can be greatly improved. Furthermore, this document presents an application of this generic Song & Qin Expires May 5, 2007 [Page 1] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 scheme in video communication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Forward erasure correction . . . . . . . . . . . . . . . . . . 4 3. A Generic payload format for FEC and interleaving . . . . . . 5 3.1. FEC algorithm with unequal error protection . . . . . . . 6 3.2. Interleaving FEC encoded blocks . . . . . . . . . . . . . 7 3.3. Encapsulating interleaved blocks into RTP packets . . . . 8 3.4. Delay consideration and parameter determination . . . . . 8 3.5. Detecting packet losses . . . . . . . . . . . . . . . . . 9 4. An application of FEC and interleaving in video communication . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. characteristics of the video data . . . . . . . . . . . . 11 4.2. Design consideration . . . . . . . . . . . . . . . . . . . 11 4.2.1. the more important video data . . . . . . . . . . . . 11 4.2.2. the less important video data . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Song & Qin Expires May 5, 2007 [Page 2] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 1. Introduction The nature of real-time video applications implies that they usually have more stringent delay requirements than normal data transmissions. As a result, the retransmission of lost packets is generally not an acceptable option for such applications. In these cases, a better method is to attempt to recover the information contained in lost packets through Forward Error Correction (FEC) [RFC3453]. On the other hand, interleaving the data streams from the sender can mitigate quality degradation due to packet loss, especially burst loss. This document specifies a new RTP payload format, which can guarantee the QoS of video communication, and as an example, provides the description of its application to video data streams. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant RTP implementations. Song & Qin Expires May 5, 2007 [Page 3] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 2. Forward erasure correction In the general literature, FEC refers to the ability to overcome both erasure errors and bit-level corruptions [RFC3558]. However, in the case of an IP-based protocol, either the network layer detects corrupted packets and discard them, or the transport layer uses packet authentication mechanism to discard corrupted packets. Therefore the primary application of FEC codes to IP protocols is one as an erasure code. On the sender's side, the payloads are generated and processed using an FEC erasure encoder, and on the receiver's side, objects are reassembled from the reception of the packets containing the FEC encoded payloads by an FEC erasure decoder using the corresponding FEC mechanism. A (N, K) FEC code works in the following way. The input to a block FEC encoder are origin data blocks (ODBs) of equal length grouped into batches with one batch at a time. Each batch contains K ODBs, and for each batch of input ODBs, the encoder then generates a total of N>K encoded data blocks (EDB) composed of the K ODBs and the N-K redundant check blocks. The whole group of these N EDBs is referred to as an FEC unit. A block FEC decoder has the property that any K of the N EDBs is sufficient to reconstruct the original K ODBs. A typical (N, K) erasure code is known as Tornado code. Song & Qin Expires May 5, 2007 [Page 4] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 3. A Generic payload format for FEC and interleaving In order to improve the ability of the receiver to tolerate the packet losses and guarantee the QoS of real-time communications, especially video communications, this section presents a novel generic RTP payload format for which attempts to relieve if not eliminate the impacts of packet losses. The new RTP payload format is defined as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |C| R |FECType|FEC subtype| packet index | block size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | one or more encoded data blocks | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RTP header fields take the values described in the RTP specification [RFC3550]. The fields for generic FEC and interleaving are specified as follows: C: 1 bits Reserved, MUST be set to zero by the sender, SHOULD be ignored by the receiver. R: 3 bit The field indicates the type of interleaving algorithms used for the RTP payload. A value of zero means no interleaving is used for this RTP payload,the output data is time-ordered. FEC type: 4 bits The field indicates the type of FEC algorithms (erasure code) used for the RTP payload. A value of zero means no FEC is used for this RTP payload. The mapping of non-zero FEC type values to FEC algorithms is not to be specified in this document. FEC subtype: 6 bits The field is used to define the different subtype of FEC type which is defined above. The basic idea of using two fields FEC type and FEC subtype to identify a certain FEC code is that the whole family of FEC codes can be divided into different subfamilies and each subfamily contains FEC codes with similar characteristics and generation mechanisms. The FEC type field indicates which subfamily a certain FEC code is in and the FEC Song & Qin Expires May 5, 2007 [Page 5] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 subtype field further indicates in the given subfamily what generation parameters are used for this certain FEC code. Usually FEC codes in a subfamily have similar generation mechanism but different generation parameters, and as a result, different protection strengths. This field SHOULD be ignored if FEC type is zero. For non-zero FEC subtype values, parameters of FEC algorithm, such as the values of N and K for (N, K) erasure code, SHOULD be uniquely determined by this field. Therefore, for a given non-zero value of the FEC subtype field, parameters of FEC algorithm can be exactly derived. Packet index: 10bits If interleaving is used, This field indicates zero-based index within an interleaving group which is used to tell the indices of lost packets in each interleaving group (see section 3.2) which are important to FEC decoding. In contrast, the SN field in RTP header tells the indices of the lost packets. If interleaving is not used, this field indicates zero-based block index within an FEC unit which is used to tell the indices of lost blocks in each FEC unit. The value of this field SHOULD be less than N, which is the number of EDBs comprising an FEC unit. Block size (B): 8 bits Each data block contained in an FEC unit SHOULD have the same size, and this field indicates the number of octets in a block. 3.1. FEC algorithm with unequal error protection Real-time data in a RTP session may have different relative importance to the receiver. Generally speaking, the encoded stream of a video sequence is launched frame by frame. These frames have different importance to the video decoder, For example, in H.264 video communication, reference frames are critical to a decoder to reconstruct following pictures, and prediction frames are used to reconstruct just one picture based on the previous reference frame. Losses of reference frames may cause far more serious disasters to the video decoder in the sense that the video decoder can be forced into an interruption lasting a rather long period. Data with different importance MAY be unequally protected with different FEC algorithms. if this is the case, only the data with the same or similar importance can be encapsulated into a RTP packet. In Song & Qin Expires May 5, 2007 [Page 6] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 other words, only one FEC algorithm can be used throughout a RTP packet. The encoded stream from the sender is equally divided into a sequence of origin data blocks, and each block has the size of B octets. Every K data blocks will be encoded using an FEC algorithm to generate N (N>K) encoded blocks. When unequal protection is enabled, if the total number of octets of the encoded stream with the same importance is not divided exactly by K*B. Padding octets should be appended to enable FEC algorithm to work correctly. The negotiation on FEC algorithms acceptable to both the sender and the receiver is not to be specified in this document. 3.2. Interleaving FEC encoded blocks Bundling is used to spread the transmission overhead of the RTP and payload headers over multiple encoded blocks so as to maximize the bandwidth efficiency and minimize the transmission latency. Interleaving [RFC3453] additionally reduces the receiver's perception the negative effects of data losses by spreading such losses over non-consecutive blocks. Interleaving is meaningful only if more than one encoded blocks are put into a single RTP packet. All receivers MUST support interleaving. The senders MAY optionally support interleaving. Given a sequence of EDBs from the sender, numbered 0, .., n, and a (N, K) FEC algorithm. Note that n SHOULD be divided exactly by N, this can be achieved using padding mentioned in section 3.1. These n EDBs will be organized to form F=n/N FEC units, and will be further interleaved into G=(F+U-1)/U groups with interleaving length N where U is the maximum bundling value, i.e., the maximum FEC unit number that can be contained in a RTP packet. The blocks are placed into RTP packets as follows: First RTP Packet in Interleaved group 0: Interleave index=0 block 0, block N, block 2N, ... block (U-1)*N for a total of U blocks Second RTP Packet in Interleaved group 0: Interleave index=1 Song & Qin Expires May 5, 2007 [Page 7] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 block 1, block N+1, block 2N+1, ... block (U-1)*N+1 for a total of U blocks This continues to the last RTP packet in the interleave group 0: Nth RTP Packet in Interleaved group 0: Interleave index=N-1 block N-1, block 2N-1, block 3N-1, ... block U*N-1 for a total of U blocks This continues to the interleaved group G-2. Each RTP packet belongs to these G-1 interleaving groups contain U encoded blocks Until now, there are still F mod U FEC units to be interleaved for interleaved group G-1. The same interleaving method as mentioned above is used for interleaving group G-1 with each RTP packet containing only V=F mod U encoded blocks. 3.3. Encapsulating interleaved blocks into RTP packets A RTP packet MUST contain exactly one or more encoded blocks, i.e., one encoded block SHOULD NOT span two or more RTP packets. The sender MUST not contain more data blocks in a single RTP packet than can be fitted in the MTU (maximum transfer unit) of the underlying transport protocol. The following formula can be used to calculate the number of blocks in a RTP packet. RTP packet size can be obtained from the underlying transport layer. U = (RTP_packet_size - RTP_header_length - payload_header_length) / B When interleaving is enabled, the bundle value V always equals to the block number in a RTP packet. and when interleaving is not used, to mitigate the impact of burst packet loss to the FEC decoder, only one FEC block SHOULD be encapsulated in every RTP packet. 3.4. Delay consideration and parameter determination FEC and interleaving reduce the effect of pack losses at the cost of increasing the delay. Large values of N, K or U increase not only the ability of the receiver to be tolerant of packet losses, but also the delay. Tradeoff between the low end-to-end delay and great tolerance for packet losses should be made in the choice of FEC and interleaving parameters. Song & Qin Expires May 5, 2007 [Page 8] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 3.5. Detecting packet losses From the difference of the SN fields of two consecutive received RTP packets, the number of lost packets can be determined. When FEC is used, this information is insufficient for an FEC decoder to recover the lost packet. To make the FEC decoder work, the position of the lost packets in their corresponding FEC unit need to be determined. 1. If the data are neither protected by the FEC and nor interleaved, the lost packet cannot be recovered. 2. If the data are protected by the FEC but are not interleaved. The receiver determines the number of data blocks N for all RTP packets in an FEC units by FEC type and FEC subtype field in the first received RTP packet of the FEC unit. Note that this may not be the first RTP packet of the FEC unit if packets are lost or delivered out of order by the underlying transport. Given an RTP packet with sequence number S, N (block number of an FEC unit), block index I, the FEC unit consists of this RTP packet and other RTP packets with sequence numbers ranging between S-I mod 65536 to S-I+N mod 65536 inclusively. In other words, one FEC unit consists of N RTP packets with sequential sequence numbers. The indices of lost packets in a given FEC unit can be detected quickly from the break of interleaving index field. This information is needed by the FEC decoder to recover the lost packets. 3. If the data are not only protected by FEC but also interleaved. The receiver determines the expected bundling value V for all RTP packets in an interleaved group by the number of encoded blocks bundled in the first received RTP packet of the interleaved group received. Note that this may not be the first RTP packet of the interleaved group if packets are lost or delivered out of order by the underlying transport. Given an RTP packet with sequence number S, interleaving length N which can be derived from the FEC subtype field, interleaving index value I, and bundling value U, the interleaved group consists of this RTP packet and other RTP packets with sequence numbers ranging between S-I mod 65536 to S-I+N mod 65536 inclusively. In other words, the interleaved group always consists of N RTP packets with sequential sequence numbers. The bundling values for all RTP packets in an interleaved group MUST be the same. The indices of lost packets in a given interleaved group can be detected quickly from the interleaving index field. This information is needed by the FEC decoder to recover the lost packets. The informations of the unrecovered packets, with the information of the corresponding FEC units or the corresponding interleaving group, Song & Qin Expires May 5, 2007 [Page 9] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 should be reported to the high application. Song & Qin Expires May 5, 2007 [Page 10] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 4. An application of FEC and interleaving in video communication 4.1. characteristics of the video data The importance of the video data are different. In a picture sequence, the data that are close to the beginning of the picture sequence are in general more important and they are more likely to carry more information than the data further back in the picture sequence. In the other hand, the data which have the different function have the different importance, for example, for H.264 video data, I-slices are critical to the receiver. The data which are located between two adjacent I-slices, called a picture sequence, have less importance than I-slices. 4.2. Design consideration Video code stream is transmitted or stored based on frame. As it is known, different data have different significances. For the above mentioned reasons, the video encoded streams are unequally protected with different FEC protection strengths based on their significances. The more important data are protected by the stronger protection schemes. 4.2.1. the more important video data the more important video data should be strongly protected. and the data should not be protected with interleaving, because the interleaving algorithm will introduce the more delay. The time- ordered frames have the size of W octets, the data are equally divided into k=W/B data blocks, each data block has the size of B octets. If W is not divided exactly by B, padding octets should be appended to enable FEC algorithm to work correctly. For every K data blocks, N encoded blocks are generated via a strong FEC algorithm with more redundancy. To mitigate the impact of burst packet loss to the FEC decoder, exactly one FEC block is encapsulated in one RTP packet. The format of encapsulation of the more important data is defined as follows. +-------------+ +------------+--------------+ +---------------+ |data block #1|...|data block k|check block #1|...|check block N-k| +-------------+ +------------+--------------+ +---------------+ ^ ^ ^ ^ ^ ^ ^ |RTP packet #1|...|RTP packet k|RTP packet k+1|...| RTP packet N | Song & Qin Expires May 5, 2007 [Page 11] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 4.2.2. the less important video data Assuming the total number of octets of the less important video data which belong to the same picture sequence is W bytes, and the total number of octets, excluding the redundant octets appended by FEC, of an interleaved group is U*K*B. All these data can be divided into W/(U*K*B) groups, which will be protected with a normal FEC algorithm, interleaved and encapsulated. There may remain W mod (U*K*B) octets. These octets are encapsulated directly, i.e., they are neither protected with FEC nor interleaved. Because they are at the end of the picture sequence, hence have lower importance. Even these octets are lostGBP[not] their impacts on reconstructed pictures will be eliminated by the following I-slice. The format of encapsulation of the less important data which are protected with FEC and interleaving algorithms is defined as follows. +--------+--------+--------+ +----------+----------+ +--------+ | 0 | 1 | 2 |...| k-1 | k |...| N-1 | +--------+--------+--------+ +----------+----------+ +--------+ | N | N+1 | N+2 |...| N+k-1 | N+k |...| 2N-1 | +--------+--------+--------+ +----------+----------+ +--------+ | ... | ... | ... | | ... | ... | | ... | +--------+--------+--------+ +----------+----------+ +--------+ | (U-1)N |(U-1)N+1|(U-1)N+2|...|(U-1)N+k-1| (U-1)N+k |...| U*N-1 | +--------+--------+--------+ +----------+----------+ +--------+ ^ ^ ^ ^ ^ ^ ^ ^ ^ |RTP |RTP |RTP |...|RTP |RTP |...|RTP | |packet 1|packet 2|packet 3| |packet k |packet k+1| |packet N| Song & Qin Expires May 5, 2007 [Page 12] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 5. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and any appropriate RTP profile. This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations. A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. The usage of authentication of at least the RTP packet is RECOMMENDED As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it. A security review of this payload format found no additional considerations beyond those in the RTP specification. Song & Qin Expires May 5, 2007 [Page 13] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 6. Conclusion Using the novel generic RTP payload format, forward erasure correction and interleaving described in this document, the capability of error resilience for real-time communications over error-prone IP networks with packet losses can be improved. Furthermore, this method is simple and easy-to-implement. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 3550, BCP 14, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport protocol for Real-Time Applications", RFC 3550, July 2003. [RFC3453] Frederick, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002. [RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003. Song & Qin Expires May 5, 2007 [Page 14] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 Authors' Addresses Bin Song Xidian Univ. 2 South TaiBai Road Xi'an, Shaanxi 710071 CN Phone: +86 29 8820 4409 Email: bsong@mail.xidian.edu.cn Hao Qin Xidian Univ. 2 South TaiBai Road Xi'an, Shaanxi 710071 CN Phone: +86 29 8820 3614 Email: hqin@mail.xidian.edu.cn Song & Qin Expires May 5, 2007 [Page 15] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Song & Qin Expires May 5, 2007 [Page 16] ------=_Part_60855_12517659.1161831885322 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Dear members,

There is one document we want to be discussed. It is not an official document, we will submit it officially as soon as the IETF allows new submissions.
The document presents a generic RTP payload format for guaranteeing QoS of video communication with FEC technique.

Request you kindly provide the feedback.

Best regards,
 
 

 


FECFrame                                                          B. Song
Internet-Draft                                                    H. Qin
Expires: May 5, 2007                                        Xidian Univ.
                                                                Nov 2006


   Generic RTP Payload Format guaranteeing QoS of Video communication
                       draft-bsong-fecframe-gfec-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 5, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document presents a new generic RTP payload format for
   guaranteeing QoS of video communication, and describes a generic
   scheme to packetize video stream for transport using the presented
   RTP payload format.  Forward erasure correction and interleaving are
   used in the scheme to reduce the impact of the packet losses.  Video
   stream may be unequally FEC protected with different strength such
   that the QoS of video communication can be greatly improved.
   Furthermore, this document presents an application of this generic

 

Song & Qin                 Expires May 5, 2007                  [Page 1]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


   scheme in video communication.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Forward erasure correction . . . . . . . . . . . . . . . . . .  4
   3.  A Generic payload format for FEC and interleaving  . . . . . .  5
     3.1.  FEC algorithm with unequal error protection  . . . . . . .  6
     3.2.  Interleaving FEC encoded blocks  . . . . . . . . . . . . .  7
     3.3.  Encapsulating interleaved blocks into RTP packets  . . . .  8
     3.4.  Delay consideration and parameter determination  . . . . .  8
     3.5.  Detecting packet losses  . . . . . . . . . . . . . . . . .  9
   4.  An application of FEC and interleaving in video
       communication  . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  characteristics of the video data  . . . . . . . . . . . . 11
     4.2 .  Design consideration . . . . . . . . . . . . . . . . . . . 11
       4.2.1.  the more important video data  . . . . . . . . . . . . 11
       4.2.2.  the less important video data  . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

 

 

 

 

 

 

 

 

 

 

 

 


Song & Qin                 Expires May 5, 2007                  [Page 2]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


1.  Introduction

   The nature of real-time video applications implies that they usually
   have more stringent delay requirements than normal data
   transmissions.  As a result, the retransmission of lost packets is
   generally not an acceptable option for such applications.  In these
   cases, a better method is to attempt to recover the information
   contained in lost packets through Forward Error Correction (FEC)
   [RFC3453].  On the other hand, interleaving the data streams from the
   sender can mitigate quality degradation due to packet loss,
   especially burst loss.  This document specifies a new RTP payload
   format, which can guarantee the QoS of video communication, and as an
   example, provides the description of its application to video data
   streams.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant RTP
   implementations.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Song & Qin                 Expires May 5, 2007                  [Page 3]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


2.  Forward erasure correction

   In the general literature, FEC refers to the ability to overcome both
   erasure errors and bit-level corruptions [RFC3558].  However, in the
   case of an IP-based protocol, either the network layer detects
   corrupted packets and discard them, or the transport layer uses
   packet authentication mechanism to discard corrupted packets.
   Therefore the primary application of FEC codes to IP protocols is one
   as an erasure code.  On the sender's side, the payloads are generated
   and processed using an FEC erasure encoder, and on the receiver's
   side, objects are reassembled from the reception of the packets
   containing the FEC encoded payloads by an FEC erasure decoder using
   the corresponding FEC mechanism.

   A (N, K) FEC code works in the following way.  The input to a block
   FEC encoder are origin data blocks (ODBs) of equal length grouped
   into batches with one batch at a time.  Each batch contains K ODBs,
   and for each batch of input ODBs, the encoder then generates a total
   of N>K encoded data blocks (EDB) composed of the K ODBs and the N-K
   redundant check blocks.  The whole group of these N EDBs is referred
   to as an FEC unit.  A block FEC decoder has the property that any K
   of the N EDBs is sufficient to reconstruct the original K ODBs.  A
   typical (N, K) erasure code is known as Tornado code.

 

 

 

 

 

 

 

 

 

 

 

 

 


Song & Qin                 Expires May 5, 2007                  [Page 4]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


3.  A Generic payload format for FEC and interleaving

   In order to improve the ability of the receiver to tolerate the
   packet losses and guarantee the QoS of real-time communications,
   especially video communications, this section presents a novel
   generic RTP payload format for which attempts to relieve if not
   eliminate the impacts of packet losses.

   The new RTP payload format is defined as follows.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         RTP Header                            |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |C|  R  |FECType|FEC subtype|     packet index  | block size    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               one or more encoded data blocks                 |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The RTP header fields take the values described in the RTP
   specification [RFC3550].  The fields for generic FEC and interleaving
   are specified as follows:

   C: 1 bits
      Reserved, MUST be set to zero by the sender, SHOULD be ignored by
      the receiver.

   R: 3 bit
      The field indicates the type of interleaving algorithms used for
      the RTP payload.  A value of zero means no interleaving is used
      for this RTP payload,the output data is time-ordered.

   FEC type: 4 bits
      The field indicates the type of FEC algorithms (erasure code) used
      for the RTP payload.  A value of zero means no FEC is used for
      this RTP payload.  The mapping of non-zero FEC type values to FEC
      algorithms is not to be specified in this document.

   FEC subtype: 6 bits
      The field is used to define the different subtype of FEC type
      which is defined above.  The basic idea of using two fields FEC
      type and FEC subtype to identify a certain FEC code is that the
      whole family of FEC codes can be divided into different
      subfamilies and each subfamily contains FEC codes with similar
      characteristics and generation mechanisms.  The FEC type field
      indicates which subfamily a certain FEC code is in and the FEC

 

Song & Qin                 Expires May 5, 2007                  [Page 5]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


      subtype field further indicates in the given subfamily what
      generation parameters are used for this certain FEC code.  Usually
      FEC codes in a subfamily have similar generation mechanism but
      different generation parameters, and as a result, different
      protection strengths.

      This field SHOULD be ignored if FEC type is zero.  For non-zero
      FEC subtype values, parameters of FEC algorithm, such as the
      values of N and K for (N, K) erasure code, SHOULD be uniquely
      determined by this field.  Therefore, for a given non-zero value
      of the FEC subtype field, parameters of FEC algorithm can be
      exactly derived.

   Packet index: 10bits

      If interleaving is used, This field indicates zero-based index
      within an interleaving group which is used to tell the indices of
      lost packets in each interleaving group (see section 3.2) which
      are important to FEC decoding.  In contrast, the SN field in RTP
      header tells the indices of the lost packets.

      If interleaving is not used, this field indicates zero-based block
      index within an FEC unit which is used to tell the indices of lost
      blocks in each FEC unit.

      The value of this field SHOULD be less than N, which is the number
      of EDBs comprising an FEC unit.

   Block size (B): 8 bits
      Each data block contained in an FEC unit SHOULD have the same
      size, and this field indicates the number of octets in a block.

3.1.  FEC algorithm with unequal error protection

   Real-time data in a RTP session may have different relative
   importance to the receiver.  Generally speaking, the encoded stream
   of a video sequence is launched frame by frame.  These frames have
   different importance to the video decoder, For example, in H.264
   video communication, reference frames are critical to a decoder to
   reconstruct following pictures, and prediction frames are used to
   reconstruct just one picture based on the previous reference frame.
   Losses of reference frames may cause far more serious disasters to
   the video decoder in the sense that the video decoder can be forced
   into an interruption lasting a rather long period.

   Data with different importance MAY be unequally protected with
   different FEC algorithms. if this is the case, only the data with the
   same or similar importance can be encapsulated into a RTP packet.  In

 

Song & Qin                 Expires May 5, 2007                  [Page 6]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


   other words, only one FEC algorithm can be used throughout a RTP
   packet.

   The encoded stream from the sender is equally divided into a sequence
   of origin data blocks, and each block has the size of B octets.
   Every K data blocks will be encoded using an FEC algorithm to
   generate N (N>K) encoded blocks.

   When unequal protection is enabled, if the total number of octets of
   the encoded stream with the same importance is not divided exactly by
   K*B. Padding octets should be appended to enable FEC algorithm to
   work correctly.

   The negotiation on FEC algorithms acceptable to both the sender and
   the receiver is not to be specified in this document.

3.2.  Interleaving FEC encoded blocks

   Bundling is used to spread the transmission overhead of the RTP and
   payload headers over multiple encoded blocks so as to maximize the
   bandwidth efficiency and minimize the transmission latency.
   Interleaving [RFC3453] additionally reduces the receiver's perception
   the negative effects of data losses by spreading such losses over
   non-consecutive blocks.  Interleaving is meaningful only if more than
   one encoded blocks are put into a single RTP packet.

   All receivers MUST support interleaving.  The senders MAY optionally
   support interleaving.

   Given a sequence of EDBs from the sender, numbered 0, .., n, and a
   (N, K) FEC algorithm.  Note that n SHOULD be divided exactly by N,
   this can be achieved using padding mentioned in section 3.1.  These n
   EDBs will be organized to form F=n/N FEC units, and will be further
   interleaved into G=(F+U-1)/U groups with interleaving length N where
   U is the maximum bundling value, i.e., the maximum FEC unit number
   that can be contained in a RTP packet.  The blocks are placed into
   RTP packets as follows:

   First RTP Packet in Interleaved group 0:

   Interleave index=0

   block 0, block N, block 2N, ... block (U-1)*N for a total of U blocks

   Second RTP Packet in Interleaved group 0:

   Interleave index=1

 


Song & Qin                 Expires May 5, 2007                  [Page 7]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


   block 1, block N+1, block 2N+1, ... block (U-1)*N+1 for a total of U
   blocks

   This continues to the last RTP packet in the interleave group 0:

   Nth RTP Packet in Interleaved group 0:

   Interleave index=N-1

   block N-1, block 2N-1, block 3N-1, ... block U*N-1 for a total of U
   blocks

   This continues to the interleaved group G-2.  Each RTP packet belongs
   to these G-1 interleaving groups contain U encoded blocks

   Until now, there are still F mod U FEC units to be interleaved for
   interleaved group G-1.  The same interleaving method as mentioned
   above is used for interleaving group G-1 with each RTP packet
   containing only V=F mod U encoded blocks.

3.3.  Encapsulating interleaved blocks into RTP packets

   A RTP packet MUST contain exactly one or more encoded blocks, i.e.,
   one encoded block SHOULD NOT span two or more RTP packets.  The
   sender MUST not contain more data blocks in a single RTP packet than
   can be fitted in the MTU (maximum transfer unit) of the underlying
   transport protocol.

   The following formula can be used to calculate the number of blocks
   in a RTP packet.  RTP packet size can be obtained from the underlying
   transport layer.

   U = (RTP_packet_size - RTP_header_length - payload_header_length) / B

   When interleaving is enabled, the bundle value V always equals to the
   block number in a RTP packet. and when interleaving is not used, to
   mitigate the impact of burst packet loss to the FEC decoder, only one
   FEC block SHOULD be encapsulated in every RTP packet.

3.4.  Delay consideration and parameter determination

   FEC and interleaving reduce the effect of pack losses at the cost of
   increasing the delay.  Large values of N, K or U increase not only
   the ability of the receiver to be tolerant of packet losses, but also
   the delay.  Tradeoff between the low end-to-end delay and great
   tolerance for packet losses should be made in the choice of FEC and
   interleaving parameters.

 


Song & Qin                 Expires May 5, 2007                  [Page 8]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


3.5.  Detecting packet losses

   From the difference of the SN fields of two consecutive received RTP
   packets, the number of lost packets can be determined.  When FEC is
   used, this information is insufficient for an FEC decoder to recover
   the lost packet.  To make the FEC decoder work, the position of the
   lost packets in their corresponding FEC unit need to be determined.

   1.  If the data are neither protected by the FEC and nor interleaved,
       the lost packet cannot be recovered.

   2.  If the data are protected by the FEC but are not interleaved.
       The receiver determines the number of data blocks N for all RTP
       packets in an FEC units by FEC type and FEC subtype field in the
       first received RTP packet of the FEC unit.  Note that this may
       not be the first RTP packet of the FEC unit if packets are lost
       or delivered out of order by the underlying transport.  Given an
       RTP packet with sequence number S, N (block number of an FEC
       unit), block index I, the FEC unit consists of this RTP packet
       and other RTP packets with sequence numbers ranging between S-I
       mod 65536 to S-I+N mod 65536 inclusively.  In other words, one
       FEC unit consists of N RTP packets with sequential sequence
       numbers.  The indices of lost packets in a given FEC unit can be
       detected quickly from the break of interleaving index field.
       This information is needed by the FEC decoder to recover the lost
       packets.

   3.  If the data are not only protected by FEC but also interleaved.
       The receiver determines the expected bundling value V for all RTP
       packets in an interleaved group by the number of encoded blocks
       bundled in the first received RTP packet of the interleaved group
       received.  Note that this may not be the first RTP packet of the
       interleaved group if packets are lost or delivered out of order
       by the underlying transport.  Given an RTP packet with sequence
       number S, interleaving length N which can be derived from the FEC
       subtype field, interleaving index value I, and bundling value U,
       the interleaved group consists of this RTP packet and other RTP
       packets with sequence numbers ranging between S-I mod 65536 to
       S-I+N mod 65536 inclusively.  In other words, the interleaved
       group always consists of N RTP packets with sequential sequence
       numbers.  The bundling values for all RTP packets in an
       interleaved group MUST be the same.  The indices of lost packets
       in a given interleaved group can be detected quickly from the
       interleaving index field.  This information is needed by the FEC
       decoder to recover the lost packets.

   The informations of the unrecovered packets, with the information of
   the corresponding FEC units or the corresponding interleaving group,

 

Song & Qin                 Expires May 5, 2007                  [Page 9]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


   should be reported to the high application.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Song & Qin                 Expires May 5, 2007                 [Page 10]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


4.  An application of FEC and interleaving in video communication

4.1.  characteristics of the video data

   The importance of the video data are different.  In a picture
   sequence, the data that are close to the beginning of the picture
   sequence are in general more important and they are more likely to
   carry more information than the data further back in the picture
   sequence.  In the other hand, the data which have the different
   function have the different importance, for example, for H.264 video
   data, I-slices are critical to the receiver.  The data which are
   located between two adjacent I-slices, called a picture sequence,
   have less importance than I-slices.

4.2.  Design consideration

   Video code stream is transmitted or stored based on frame.  As it is
   known, different data have different significances.  For the above
   mentioned reasons, the video encoded streams are unequally protected
   with different FEC protection strengths based on their significances.
   The more important data are protected by the stronger protection
   schemes.

4.2.1.  the more important video data

   the more important video data should be strongly protected. and the
   data should not be protected with interleaving, because the
   interleaving algorithm will introduce the more delay.  The time-
   ordered frames have the size of W octets, the data are equally
   divided into k=W/B data blocks, each data block has the size of B
   octets.  If W is not divided exactly by B, padding octets should be
   appended to enable FEC algorithm to work correctly.  For every K data
   blocks, N encoded blocks are generated via a strong FEC algorithm
   with more redundancy.  To mitigate the impact of burst packet loss to
   the FEC decoder, exactly one FEC block is encapsulated in one RTP
   packet.

   The format of encapsulation of the more important data is defined as
   follows.

    +-------------+   +------------+--------------+   +---------------+
    |data block #1|...|data block k|check block #1|...|check block N-k|
    +-------------+   +------------+--------------+   +---------------+
    ^             ^   ^            ^              ^   ^               ^
    |RTP packet #1|...|RTP packet k|RTP packet k+1|...| RTP packet N  |

 

 


Song & Qin                 Expires May 5, 2007                 [Page 11]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


4.2.2.  the less important video data

   Assuming the total number of octets of the less important video data
   which belong to the same picture sequence is W bytes, and the total
   number of octets, excluding the redundant octets appended by FEC, of
   an interleaved group is U*K*B. All these data can be divided into
   W/(U*K*B) groups, which will be protected with a normal FEC
   algorithm, interleaved and encapsulated.  There may remain W mod
   (U*K*B) octets.  These octets are encapsulated directly, i.e., they
   are neither protected with FEC nor interleaved.  Because they are at
   the end of the picture sequence, hence have lower importance.  Even
   these octets are lostGBP[not] their impacts on reconstructed pictures
   will be eliminated by the following I-slice.

   The format of encapsulation of the less important data which are
   protected with FEC and interleaving algorithms is defined as follows.


    +--------+--------+--------+   +----------+----------+   +--------+
    |    0   |    1   |    2   |...|   k-1    |    k     |...|   N-1  |
    +--------+--------+--------+   +----------+----------+   +--------+
    |    N   |   N+1  |   N+2  |...|  N+k-1   |   N+k    |...|  2N-1  |
    +--------+--------+--------+   +----------+----------+   +--------+
    |   ...  |   ...  |   ...  |   |   ...    |   ...    |   |   ...  |
    +--------+--------+--------+   +----------+----------+   +--------+
    | (U-1)N |(U-1)N+1|(U-1)N+2|...|(U-1)N+k-1| (U-1)N+k |...|  U*N-1 |
    +--------+--------+--------+   +----------+----------+   +--------+
    ^        ^        ^        ^   ^          ^          ^   ^        ^
    |RTP     |RTP     |RTP     |...|RTP       |RTP       |...|RTP     |
    |packet 1|packet 2|packet 3|   |packet k  |packet k+1|   |packet N|

 

 

 

 

 

 

 

 

 

 

Song & Qin                 Expires May 5, 2007                 [Page 12]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


5.  Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550], and any appropriate RTP profile.  This
   implies that confidentiality of the media streams is achieved by
   encryption.  Because the data compression used with this payload
   format is applied end-to-end, encryption may be performed after
   compression so there is no conflict between the two operations.

   A potential denial-of-service threat exists for data encoding using
   compression techniques that have non-uniform receiver-end
   computational load.  The attacker can inject pathological datagrams
   into the stream which are complex to decode and cause the receiver to
   be overloaded.  The usage of authentication of at least the RTP
   packet is RECOMMENDED

   As with any IP-based protocol, in some circumstances a receiver may
   be overloaded simply by the receipt of too many packets, either
   desired or undesired.  Network-layer authentication may be used to
   discard packets from undesired sources, but the processing cost of
   the authentication itself may be too high.  In a multicast
   environment, pruning of specific sources may be implemented in future
   versions of IGMP and in multicast routing protocols to allow a
   receiver to select which sources are allowed to reach it.

   A security review of this payload format found no additional
   considerations beyond those in the RTP specification.

 

 

 

 

 

 

 

 

 

 

 

Song & Qin                 Expires May 5, 2007                 [Page 13]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


6.  Conclusion

   Using the novel generic RTP payload format, forward erasure
   correction and interleaving described in this document, the
   capability of error resilience for real-time communications over
   error-prone IP networks with packet losses can be improved.
   Furthermore, this method is simple and easy-to-implement.

7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 3550, BCP 14, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport protocol for Real-Time
              Applications", RFC 3550, July 2003.

   [RFC3453]  Frederick, M., Vicisano, L., Gemmell, J., Rizzo, L.,
              Handley, M., and J. Crowcroft, "The Use of Forward Error
              Correction (FEC) in Reliable Multicast", RFC 3453,
              December 2002.

   [RFC3558]  Li, A., "RTP Payload Format for Enhanced Variable Rate
              Codecs (EVRC) and Selectable Mode Vocoders (SMV)",
              RFC 3558, July 2003.

 

 

 

 

 

 

 

 

 

 

 

 


Song & Qin                 Expires May 5, 2007                 [Page 14]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


Authors' Addresses

   Bin Song
   Xidian Univ.
   2 South TaiBai Road
   Xi'an, Shaanxi  710071
   CN

   Phone: +86 29 8820 4409
   Email: bsong@mail.xidian.edu.cn


   Hao Qin
   Xidian Univ.
   2 South TaiBai Road
   Xi'an, Shaanxi  710071
   CN

   Phone: +86 29 8820 3614
   Email: hqin@mail.xidian.edu.cn

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Song & Qin                 Expires May 5, 2007                 [Page 15]

Internet-Draft     RTP Payload Format guaranteeing QoS          Nov 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

 


Song & Qin                 Expires May 5, 2007                 [Page 16]

------=_Part_60855_12517659.1161831885322-- --===============0805670028== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe --===============0805670028==-- From fecframe-bounces@ietf.org Wed Oct 25 23:39:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcw5r-0008EX-Cq; Wed, 25 Oct 2006 23:39:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcw5p-0008Bw-By for fecframe@ietf.org; Wed, 25 Oct 2006 23:39:45 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcw5o-0008NY-61 for fecframe@ietf.org; Wed, 25 Oct 2006 23:39:45 -0400 Received: by ug-out-1314.google.com with SMTP id 72so240744ugd for ; Wed, 25 Oct 2006 20:39:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NEpkg8Q7IkrNzEZK+W75rPyklwLgOYb10rfViLS5jzCHqqXr1Ctix51j/3dXXP9RcR7b9m+q/ZiZpkMUp0ZmMY+hFrHD/Yjea8wcvbsWoMHh+DwZ8ZHzjws7sqMHipltgklU+GSB+NWQFkISZXWiZbYTWL/k24I5RjyfC0Gv21Y= Received: by 10.78.97.7 with SMTP id u7mr1013560hub; Wed, 25 Oct 2006 20:39:42 -0700 (PDT) Received: by 10.78.100.13 with HTTP; Wed, 25 Oct 2006 20:39:42 -0700 (PDT) Message-ID: <38c19b540610252039h437bb2bflda9dd0c07054c2f9@mail.gmail.com> Date: Wed, 25 Oct 2006 20:39:42 -0700 From: "Greg Shepherd" To: fecframe@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 717d651095a319b49fc3b6c7b72cb4dd Subject: [Fecframe] Fwd: Fecframe post from qin1921@gmail.com requires approval X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Qin will be presenting the following draft in San Diego. Thanks, Greg From: "qin hao" To: fecframe@ietf.org Date: Thu, 26 Oct 2006 11:04:45 +0800 Subject: one new document to be discussed Dear members, There is one document we want to be discussed. It is not an official document, we will submit it officially as soon as the IETF allows new submissions. The document presents a generic RTP payload format for guaranteeing QoS of video communication with FEC technique. Request you kindly provide the feedback. Best regards, FECFrame B. Song Internet-Draft H. Qin Expires: May 5, 2007 Xidian Univ. Nov 2006 Generic RTP Payload Format guaranteeing QoS of Video communication draft-bsong-fecframe-gfec-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 5, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document presents a new generic RTP payload format for guaranteeing QoS of video communication, and describes a generic scheme to packetize video stream for transport using the presented RTP payload format. Forward erasure correction and interleaving are used in the scheme to reduce the impact of the packet losses. Video stream may be unequally FEC protected with different strength such that the QoS of video communication can be greatly improved. Furthermore, this document presents an application of this generic Song & Qin Expires May 5, 2007 [Page 1] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 scheme in video communication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Forward erasure correction . . . . . . . . . . . . . . . . . . 4 3. A Generic payload format for FEC and interleaving . . . . . . 5 3.1. FEC algorithm with unequal error protection . . . . . . . 6 3.2. Interleaving FEC encoded blocks . . . . . . . . . . . . . 7 3.3. Encapsulating interleaved blocks into RTP packets . . . . 8 3.4. Delay consideration and parameter determination . . . . . 8 3.5. Detecting packet losses . . . . . . . . . . . . . . . . . 9 4. An application of FEC and interleaving in video communication . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. characteristics of the video data . . . . . . . . . . . . 11 4.2 . Design consideration . . . . . . . . . . . . . . . . . . . 11 4.2.1. the more important video data . . . . . . . . . . . . 11 4.2.2. the less important video data . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Song & Qin Expires May 5, 2007 [Page 2] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 1. Introduction The nature of real-time video applications implies that they usually have more stringent delay requirements than normal data transmissions. As a result, the retransmission of lost packets is generally not an acceptable option for such applications. In these cases, a better method is to attempt to recover the information contained in lost packets through Forward Error Correction (FEC) [RFC3453]. On the other hand, interleaving the data streams from the sender can mitigate quality degradation due to packet loss, especially burst loss. This document specifies a new RTP payload format, which can guarantee the QoS of video communication, and as an example, provides the description of its application to video data streams. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant RTP implementations. Song & Qin Expires May 5, 2007 [Page 3] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 2. Forward erasure correction In the general literature, FEC refers to the ability to overcome both erasure errors and bit-level corruptions [RFC3558]. However, in the case of an IP-based protocol, either the network layer detects corrupted packets and discard them, or the transport layer uses packet authentication mechanism to discard corrupted packets. Therefore the primary application of FEC codes to IP protocols is one as an erasure code. On the sender's side, the payloads are generated and processed using an FEC erasure encoder, and on the receiver's side, objects are reassembled from the reception of the packets containing the FEC encoded payloads by an FEC erasure decoder using the corresponding FEC mechanism. A (N, K) FEC code works in the following way. The input to a block FEC encoder are origin data blocks (ODBs) of equal length grouped into batches with one batch at a time. Each batch contains K ODBs, and for each batch of input ODBs, the encoder then generates a total of N>K encoded data blocks (EDB) composed of the K ODBs and the N-K redundant check blocks. The whole group of these N EDBs is referred to as an FEC unit. A block FEC decoder has the property that any K of the N EDBs is sufficient to reconstruct the original K ODBs. A typical (N, K) erasure code is known as Tornado code. Song & Qin Expires May 5, 2007 [Page 4] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 3. A Generic payload format for FEC and interleaving In order to improve the ability of the receiver to tolerate the packet losses and guarantee the QoS of real-time communications, especially video communications, this section presents a novel generic RTP payload format for which attempts to relieve if not eliminate the impacts of packet losses. The new RTP payload format is defined as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |C| R |FECType|FEC subtype| packet index | block size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | one or more encoded data blocks | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RTP header fields take the values described in the RTP specification [RFC3550]. The fields for generic FEC and interleaving are specified as follows: C: 1 bits Reserved, MUST be set to zero by the sender, SHOULD be ignored by the receiver. R: 3 bit The field indicates the type of interleaving algorithms used for the RTP payload. A value of zero means no interleaving is used for this RTP payload,the output data is time-ordered. FEC type: 4 bits The field indicates the type of FEC algorithms (erasure code) used for the RTP payload. A value of zero means no FEC is used for this RTP payload. The mapping of non-zero FEC type values to FEC algorithms is not to be specified in this document. FEC subtype: 6 bits The field is used to define the different subtype of FEC type which is defined above. The basic idea of using two fields FEC type and FEC subtype to identify a certain FEC code is that the whole family of FEC codes can be divided into different subfamilies and each subfamily contains FEC codes with similar characteristics and generation mechanisms. The FEC type field indicates which subfamily a certain FEC code is in and the FEC Song & Qin Expires May 5, 2007 [Page 5] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 subtype field further indicates in the given subfamily what generation parameters are used for this certain FEC code. Usually FEC codes in a subfamily have similar generation mechanism but different generation parameters, and as a result, different protection strengths. This field SHOULD be ignored if FEC type is zero. For non-zero FEC subtype values, parameters of FEC algorithm, such as the values of N and K for (N, K) erasure code, SHOULD be uniquely determined by this field. Therefore, for a given non-zero value of the FEC subtype field, parameters of FEC algorithm can be exactly derived. Packet index: 10bits If interleaving is used, This field indicates zero-based index within an interleaving group which is used to tell the indices of lost packets in each interleaving group (see section 3.2) which are important to FEC decoding. In contrast, the SN field in RTP header tells the indices of the lost packets. If interleaving is not used, this field indicates zero-based block index within an FEC unit which is used to tell the indices of lost blocks in each FEC unit. The value of this field SHOULD be less than N, which is the number of EDBs comprising an FEC unit. Block size (B): 8 bits Each data block contained in an FEC unit SHOULD have the same size, and this field indicates the number of octets in a block. 3.1. FEC algorithm with unequal error protection Real-time data in a RTP session may have different relative importance to the receiver. Generally speaking, the encoded stream of a video sequence is launched frame by frame. These frames have different importance to the video decoder, For example, in H.264 video communication, reference frames are critical to a decoder to reconstruct following pictures, and prediction frames are used to reconstruct just one picture based on the previous reference frame. Losses of reference frames may cause far more serious disasters to the video decoder in the sense that the video decoder can be forced into an interruption lasting a rather long period. Data with different importance MAY be unequally protected with different FEC algorithms. if this is the case, only the data with the same or similar importance can be encapsulated into a RTP packet. In Song & Qin Expires May 5, 2007 [Page 6] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 other words, only one FEC algorithm can be used throughout a RTP packet. The encoded stream from the sender is equally divided into a sequence of origin data blocks, and each block has the size of B octets. Every K data blocks will be encoded using an FEC algorithm to generate N (N>K) encoded blocks. When unequal protection is enabled, if the total number of octets of the encoded stream with the same importance is not divided exactly by K*B. Padding octets should be appended to enable FEC algorithm to work correctly. The negotiation on FEC algorithms acceptable to both the sender and the receiver is not to be specified in this document. 3.2. Interleaving FEC encoded blocks Bundling is used to spread the transmission overhead of the RTP and payload headers over multiple encoded blocks so as to maximize the bandwidth efficiency and minimize the transmission latency. Interleaving [RFC3453] additionally reduces the receiver's perception the negative effects of data losses by spreading such losses over non-consecutive blocks. Interleaving is meaningful only if more than one encoded blocks are put into a single RTP packet. All receivers MUST support interleaving. The senders MAY optionally support interleaving. Given a sequence of EDBs from the sender, numbered 0, .., n, and a (N, K) FEC algorithm. Note that n SHOULD be divided exactly by N, this can be achieved using padding mentioned in section 3.1. These n EDBs will be organized to form F=n/N FEC units, and will be further interleaved into G=(F+U-1)/U groups with interleaving length N where U is the maximum bundling value, i.e., the maximum FEC unit number that can be contained in a RTP packet. The blocks are placed into RTP packets as follows: First RTP Packet in Interleaved group 0: Interleave index=0 block 0, block N, block 2N, ... block (U-1)*N for a total of U blocks Second RTP Packet in Interleaved group 0: Interleave index=1 Song & Qin Expires May 5, 2007 [Page 7] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 block 1, block N+1, block 2N+1, ... block (U-1)*N+1 for a total of U blocks This continues to the last RTP packet in the interleave group 0: Nth RTP Packet in Interleaved group 0: Interleave index=N-1 block N-1, block 2N-1, block 3N-1, ... block U*N-1 for a total of U blocks This continues to the interleaved group G-2. Each RTP packet belongs to these G-1 interleaving groups contain U encoded blocks Until now, there are still F mod U FEC units to be interleaved for interleaved group G-1. The same interleaving method as mentioned above is used for interleaving group G-1 with each RTP packet containing only V=F mod U encoded blocks. 3.3. Encapsulating interleaved blocks into RTP packets A RTP packet MUST contain exactly one or more encoded blocks, i.e., one encoded block SHOULD NOT span two or more RTP packets. The sender MUST not contain more data blocks in a single RTP packet than can be fitted in the MTU (maximum transfer unit) of the underlying transport protocol. The following formula can be used to calculate the number of blocks in a RTP packet. RTP packet size can be obtained from the underlying transport layer. U = (RTP_packet_size - RTP_header_length - payload_header_length) / B When interleaving is enabled, the bundle value V always equals to the block number in a RTP packet. and when interleaving is not used, to mitigate the impact of burst packet loss to the FEC decoder, only one FEC block SHOULD be encapsulated in every RTP packet. 3.4. Delay consideration and parameter determination FEC and interleaving reduce the effect of pack losses at the cost of increasing the delay. Large values of N, K or U increase not only the ability of the receiver to be tolerant of packet losses, but also the delay. Tradeoff between the low end-to-end delay and great tolerance for packet losses should be made in the choice of FEC and interleaving parameters. Song & Qin Expires May 5, 2007 [Page 8] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 3.5. Detecting packet losses From the difference of the SN fields of two consecutive received RTP packets, the number of lost packets can be determined. When FEC is used, this information is insufficient for an FEC decoder to recover the lost packet. To make the FEC decoder work, the position of the lost packets in their corresponding FEC unit need to be determined. 1. If the data are neither protected by the FEC and nor interleaved, the lost packet cannot be recovered. 2. If the data are protected by the FEC but are not interleaved. The receiver determines the number of data blocks N for all RTP packets in an FEC units by FEC type and FEC subtype field in the first received RTP packet of the FEC unit. Note that this may not be the first RTP packet of the FEC unit if packets are lost or delivered out of order by the underlying transport. Given an RTP packet with sequence number S, N (block number of an FEC unit), block index I, the FEC unit consists of this RTP packet and other RTP packets with sequence numbers ranging between S-I mod 65536 to S-I+N mod 65536 inclusively. In other words, one FEC unit consists of N RTP packets with sequential sequence numbers. The indices of lost packets in a given FEC unit can be detected quickly from the break of interleaving index field. This information is needed by the FEC decoder to recover the lost packets. 3. If the data are not only protected by FEC but also interleaved. The receiver determines the expected bundling value V for all RTP packets in an interleaved group by the number of encoded blocks bundled in the first received RTP packet of the interleaved group received. Note that this may not be the first RTP packet of the interleaved group if packets are lost or delivered out of order by the underlying transport. Given an RTP packet with sequence number S, interleaving length N which can be derived from the FEC subtype field, interleaving index value I, and bundling value U, the interleaved group consists of this RTP packet and other RTP packets with sequence numbers ranging between S-I mod 65536 to S-I+N mod 65536 inclusively. In other words, the interleaved group always consists of N RTP packets with sequential sequence numbers. The bundling values for all RTP packets in an interleaved group MUST be the same. The indices of lost packets in a given interleaved group can be detected quickly from the interleaving index field. This information is needed by the FEC decoder to recover the lost packets. The informations of the unrecovered packets, with the information of the corresponding FEC units or the corresponding interleaving group, Song & Qin Expires May 5, 2007 [Page 9] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 should be reported to the high application. Song & Qin Expires May 5, 2007 [Page 10] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 4. An application of FEC and interleaving in video communication 4.1. characteristics of the video data The importance of the video data are different. In a picture sequence, the data that are close to the beginning of the picture sequence are in general more important and they are more likely to carry more information than the data further back in the picture sequence. In the other hand, the data which have the different function have the different importance, for example, for H.264 video data, I-slices are critical to the receiver. The data which are located between two adjacent I-slices, called a picture sequence, have less importance than I-slices. 4.2. Design consideration Video code stream is transmitted or stored based on frame. As it is known, different data have different significances. For the above mentioned reasons, the video encoded streams are unequally protected with different FEC protection strengths based on their significances. The more important data are protected by the stronger protection schemes. 4.2.1. the more important video data the more important video data should be strongly protected. and the data should not be protected with interleaving, because the interleaving algorithm will introduce the more delay. The time- ordered frames have the size of W octets, the data are equally divided into k=W/B data blocks, each data block has the size of B octets. If W is not divided exactly by B, padding octets should be appended to enable FEC algorithm to work correctly. For every K data blocks, N encoded blocks are generated via a strong FEC algorithm with more redundancy. To mitigate the impact of burst packet loss to the FEC decoder, exactly one FEC block is encapsulated in one RTP packet. The format of encapsulation of the more important data is defined as follows. +-------------+ +------------+--------------+ +---------------+ |data block #1|...|data block k|check block #1|...|check block N-k| +-------------+ +------------+--------------+ +---------------+ ^ ^ ^ ^ ^ ^ ^ |RTP packet #1|...|RTP packet k|RTP packet k+1|...| RTP packet N | Song & Qin Expires May 5, 2007 [Page 11] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 4.2.2. the less important video data Assuming the total number of octets of the less important video data which belong to the same picture sequence is W bytes, and the total number of octets, excluding the redundant octets appended by FEC, of an interleaved group is U*K*B. All these data can be divided into W/(U*K*B) groups, which will be protected with a normal FEC algorithm, interleaved and encapsulated. There may remain W mod (U*K*B) octets. These octets are encapsulated directly, i.e., they are neither protected with FEC nor interleaved. Because they are at the end of the picture sequence, hence have lower importance. Even these octets are lostGBP[not] their impacts on reconstructed pictures will be eliminated by the following I-slice. The format of encapsulation of the less important data which are protected with FEC and interleaving algorithms is defined as follows. +--------+--------+--------+ +----------+----------+ +--------+ | 0 | 1 | 2 |...| k-1 | k |...| N-1 | +--------+--------+--------+ +----------+----------+ +--------+ | N | N+1 | N+2 |...| N+k-1 | N+k |...| 2N-1 | +--------+--------+--------+ +----------+----------+ +--------+ | ... | ... | ... | | ... | ... | | ... | +--------+--------+--------+ +----------+----------+ +--------+ | (U-1)N |(U-1)N+1|(U-1)N+2|...|(U-1)N+k-1| (U-1)N+k |...| U*N-1 | +--------+--------+--------+ +----------+----------+ +--------+ ^ ^ ^ ^ ^ ^ ^ ^ ^ |RTP |RTP |RTP |...|RTP |RTP |...|RTP | |packet 1|packet 2|packet 3| |packet k |packet k+1| |packet N| Song & Qin Expires May 5, 2007 [Page 12] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 5. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and any appropriate RTP profile. This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations. A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. The usage of authentication of at least the RTP packet is RECOMMENDED As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it. A security review of this payload format found no additional considerations beyond those in the RTP specification. Song & Qin Expires May 5, 2007 [Page 13] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 6. Conclusion Using the novel generic RTP payload format, forward erasure correction and interleaving described in this document, the capability of error resilience for real-time communications over error-prone IP networks with packet losses can be improved. Furthermore, this method is simple and easy-to-implement. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 3550, BCP 14, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport protocol for Real-Time Applications", RFC 3550, July 2003. [RFC3453] Frederick, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002. [RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003. Song & Qin Expires May 5, 2007 [Page 14] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 Authors' Addresses Bin Song Xidian Univ. 2 South TaiBai Road Xi'an, Shaanxi 710071 CN Phone: +86 29 8820 4409 Email: bsong@mail.xidian.edu.cn Hao Qin Xidian Univ. 2 South TaiBai Road Xi'an, Shaanxi 710071 CN Phone: +86 29 8820 3614 Email: hqin@mail.xidian.edu.cn Song & Qin Expires May 5, 2007 [Page 15] Internet-Draft RTP Payload Format guaranteeing QoS Nov 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Song & Qin Expires May 5, 2007 [Page 16] ---------- Forwarded message ---------- From: fecframe-request@ietf.org To: Date: Subject: confirm ba1865fa332be725326bd9ea2672ae298bc5c445 If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Thu Oct 26 08:52:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4iJ-0000f1-MC; Thu, 26 Oct 2006 08:52:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4dQ-0007ue-QU for fecframe@ietf.org; Thu, 26 Oct 2006 08:47:00 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd4Ox-0004oT-Md for fecframe@ietf.org; Thu, 26 Oct 2006 08:32:09 -0400 Received: by ug-out-1314.google.com with SMTP id 72so297545ugd for ; Thu, 26 Oct 2006 05:32:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=sS3HFYl1YeUgTf+XGRr9u4oyI7gyTRj8Jkj77YNL/aBV5kQBTRj8r2yAUDXtn/p3hamdjd6mNAymIySrC6uWVAuVdnpYDfwpAUzkaqcvLzD8IIfbR2OqqsvCg/cIGPBkIGQCFQnGkJbqqS8lfigNCbb9k6om3WRs0HiON42YlRs= Received: by 10.78.171.13 with SMTP id t13mr1719976hue; Thu, 26 Oct 2006 05:32:02 -0700 (PDT) Received: by 10.78.100.13 with HTTP; Thu, 26 Oct 2006 05:32:02 -0700 (PDT) Message-ID: <38c19b540610260532u26d3f534h2390d515cadb3114@mail.gmail.com> Date: Thu, 26 Oct 2006 05:32:02 -0700 From: "Greg Shepherd" To: fecframe@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Fecframe] Agenda X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org IETF 67 FECFrame WG Agenda Tues, Nov 7th, 2006 1850-1950 Introduction / Agenda bashing Greg Shepherd 5 min Requirements Draft Update Mark Watson 15 min draft-watson-fecframe-req-00.txt Framework Draft Mark Watson 15 min draft-watson-fecframe-framework-00.txt Generic RTP Payload Format guaranteeing QOS of Video communication draft-bsong-fecframe-gfec-00.txt Qin Hao 15 min Please let me know if there is anything else. Thanks, Greg _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe