Re: [Fecframe] WGLC on draft-ietf-fecframe-dvb-al-fec-02

["Ali C. Begen (abegen)" <abegen at cisco.com>]

Hi Vincent,

See inline.

> -----Original Message-----
> From: fecframe-bounces at ietf.org [mailto:fecframe-bounces at ietf.org] On Behalf Of Vincent
> Roca
> Sent: Monday, August 31, 2009 5:50 PM
> To: Marshall Eubanks; fecframe at ietf.org
> Subject: Re: [Fecframe] WGLC on draft-ietf-fecframe-dvb-al-fec-02
> 
> Hello everybody,
> 
> After reading the above I-D, I don't have any major comments, only
> a few clarification proposals (see below).
> 
> In particular once comment 1- is addressed, then I support this
> document, taking into account the fact that I have no technical opinion
> WRT the RTP discussion in section 3.1 (sorry).
> 
> ----
> 
> 1- Explicit reference to DVB-IPTV
> 
> Currently the first reference to DVB-IPTV and DVB-IPI appear in
> section 3.1. Instead, the abstract, introduction and title only
> refer to the "DVB consortium". This is a bit misleading since the
> various DVB Technical Modules (i.e. working groups) have standardized
> several FEC schemes for the erasure channel (i.e. several FEC codes
> and several ways of using these FEC codes).
> (NB: this is the DVB UL-FEC document discussion we had during July's
>  meeting)
> 
> I suggest to:
> - mention DVB-IPTV (and possibly DVB TM-IPI, up to you) in the
>   abstract and introduction.

Sure, good idea.

> - change a little bit the long and short titles to clarify this
>   as well. For instance: "DVB-IPTV Application-Level Hybrid FEC
>   Protection" and "DVB-IPTV AL-FEC Protocol".

If there are no objections, we can do this as well.

 
> 
> 2- Introduction, p3, minor clarification proposal:
> Current text mentions 1-D interleaved parity code in the introduction,
> and then only uses the "parity encoder/decoder" (fig. 1, 2, 3) and
> "parity repair packet" (bottom of p3).
> I suggest you say once and for all that in the remaining of the
> document, "parity code" (and derivatives, like parity encoder/decoder
> or parity repair packet) will refer to the "1-D interleaved parity code"
> (and derivatives).

Will do.

 
> 
> 3- Introduction, p3, clarification needed:
> It is said:
>    "The source can be any type of media
>     such as audio, video, text or application.  However, in the AL-FEC
>     protocol, the source stream can only be an MPEG-2 transport stream."
> While I understand the idea, the juxtaposition of "can be anything",
> "however it can only be..." puzzles me a little bit. Additionally, is

Admittedly, this was taken from the al-fec spec. I will remove the former part.

> there any difference between "the source" (1st sentence) and "the
> source stream" (2nd sentence)?

Nope. Will fix this.

 
> 
> 4- Introduction, p3, RTP stream definition:
> It is said:
>    "In DVB AL-FEC, the source packets are carried in the source RTP
>     stream and the generated FEC repair packets at each layer are carried
>     in separate streams."
> For an RTP expert, it's probably sufficient. However, as far as I am
> concerned, I'd like to see a definition of an "RTP stream" and how
> the "separate streams" are distinguished (source or destination
> port/address, or both, or...). I guess there are several possibilities.

I would rather prefer to leave this discussion to rfc 3550 as other drafts do. 

> 
> 
> 5- Section 3.1., Base-Layer FEC, p5, minor clarification proposal:
> It is said:
>    "In a group of D x L source packets,
>     the XOR operation is applied to the group of the source packets whose
>     sequence numbers are L apart from each other to generate L repair
>     packets."
> Instead, I suggest:
>    "In a group of D x L source packets,
>     the XOR operation is applied to each group of D source packets whose
>     sequence numbers are L apart from each other to generate a total of L repair
>     packets."

Sure.

Thanks for the review.

-acbegen
 
> 
> Best regards,
> 
> 
>     Vincent
> _______________________________________________
> Fecframe mailing list
> Fecframe at ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe