Re: [AVT] Comments on draft-ietf-avt-ulp-11

[Magnus Westerlund <[e-mail]>]

Hi

Please see below for my comments.

Andrea Lorenzo VITALI wrote:
> I have reviewed the draft and I have a couple of questions.
> 
> 1) Have you considered the possibility to refer to non-consecutive RTP packets?
> 
> Currently, bits in the mask refer to consecutive RTP packets: starting from the
> base sequence number SN: SN+0, SN+1, SN+2 ... SN+i, where 0<=i<24 in RFC2733 and
> 0<=i<16 or 0<=i<48 in ULP.
> 
> It has been proposed in the MPEG forum to refer to non-consecutive RTP packets
> by specifying an offset L: SN+0*L, SN+1*L, ... SN+i*L, where 0<=i<24 as in RFC2733.
> 
> The document is available on the web at:
>    http://www.pro-mpeg.org/publications/pdf/Vid-on-IP-CoP3-r2.pdf
> 

I have actually seen this proposal earlier and have quite mixed feelings 
about it. For a medium to high bandwidth application I can understand 
that 24 packets are to little. 48 makes it better but only goes half-way 
to the minimal 100 packets that the MPEG-PRO requires one to support.

As I see the solution is basically an interleaving scheme and could in 
it simplest form be implemented with a signalling attribute and a change 
to the derivation bit-mask to included packet algorithm.

However before changing the format I would like to know how big interest 
it really is of such a change. See also the next comment.

[snip]
> 
> 2) I appreciated the introduction and the reference to UXP.
> 
> It would be useful to include an extensive comparison, including:
> 
>    - XOR based FEC schemes as specified in RFC2733 and draft-ietf-avt-ULP-11
> 
>    - Reed-Solomon based schemes as specified in draft-ietf-avt-UXP-07, as 
> proposed by Siemens/Nokia for 3GPP, as proposed for DVB-H (handheld) under the 
> name "MPE_FEC".
> 
>    - LDPC (low density parity check codes) based schemes as proposed by INRIA
> 
> plus other schemes based on digital fountain codes.

On this topic I don't think the ULP draft is the right place to have a 
general overview of what possible solutions that exist. It is necessary 
to have a clear applicability section. Describing under which scenarios 
it makes sense to use this format.

When it comes to UXP their is some question if that work will progress 
or be replaced with a more generic framework based on RMT like building 
blocks (draft-watson-tsvwg-fec-sf-00). This will be discussed next week 
in Paris. So there is clearly interest of getting usage of some more 
advanced and better performing FEC codes.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt