RE: [AVT] I-D ACTION:draft-ietf-avt-ulp-12.txt

["Mark Watson" <mark at digitalfountain.com>]

All,

This is a very late comment and could perhaps reasonably be ignored on
that basis. However, with the formation of the fecframe working group I
wonder if the description "Generic FEC" is liable to cause confusion. In
fact, what is specified here is a specific FEC scheme based on a short
block parity check code, albeit a flexible one.

So, I wonder if "Generic FEC" should be changed to "short block parity
check FEC" or something similar ?

The fact that this is a specific code was one of the reasons that it was
not judged to clash with the fecframe work which aims to specify a
generic framework which could be used with any FEC code.

Regards,

Mark Watson

 

-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
Colin Perkins
Sent: Saturday, November 05, 2005 7:44 AM
To: IETF AVT WG
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-ulp-12.txt 

On 25 Oct 2005, at 12:50, Internet-Drafts at ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: An RTP Payload Format for Generic FEC
> 	Author(s)	: A. Li
> 	Filename	: draft-ietf-avt-ulp-12.txt
> 	Pages		: 41
> 	Date		: 2005-10-25
> 	
> This document specifies a payload format for generic Forward
>    Error Correction (FEC) for media data encapsulated in RTP. It is
>    based on the exclusive-or (parity) operation, and it is a
>    generalized algorithms that includes Uneven Level Protection
>    (ULP). The payload format described in this draft allows end
>    systems to apply protection using arbitrary protection lengths
>    and levels, in addition to using arbitrary protection group
>    sizes. It enables complete recovery or partial recovery of the
>    critical payload and RTP header fields depending on the packet
>    loss situation. This scheme is completely backward compatible
>    with non-FEC capable hosts. Those receivers that do not know
>    about FEC can simply ignore the protection data. This
>    specification obsoletes RFC 2733 and RFC 3009.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-ulp-12.txt

I have two minor comments:

1) Sections 13.1, 13.2, 13.3 and 13.4 state "Required Parameters:  
none" and "Optional parameters: none", then define some parameters.  
This should be corrected, and the indentation in those sections fixed.

2) Could you please add an example of ULP FEC using RFC 2198  
redundant coding to section 10? It's not entirely obvious how this  
mode is used.

Otherwise, this looks good to me.

Colin

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt