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

["Adam Li" <[e-mail]>]

Hi Andrea,

Thanks for the comments.

For your question (1), it will be doable technically, though it will greatly
increase the latency of the recovery operation in additional to increasing
the complexity and the memory requirement on the receiving end. At this
stage of this draft, a better solution may be to include your proposal in
other more complex schemes in development?

For your question (2), protecting data multiple times is not as
straightforward as it looks. The recovery criteria are complicated
especially at higher level where the data is only worth recovering when all
the lower level data are recoverable. In most cases, multiple protection in
higher level is not only helpless, but also wastes bandwidth. In view of
that, the multiple protection is not really useful for any level higher than
0. In additional protecting data multiple times would greatly complicate
both the protection process and recovery process. It puts more constraint on
the protection as the length has to stay constant for all the groups. That's
the rationale for that constraint.

For your remark (1), great suggestion. When that paragraph of the draft is
first read, it is can be a little confusing between the protection level
(which is just a number) and strength of protection. I will fix it as you
suggested.

For your remark (2), thanks for the information.

Adam

> -----Original Message-----
> From: Andrea Lorenzo VITALI [mailto:[e-mail]]
> Sent: Monday, July 25, 2005 11:57 PM
> To: Adam Li
> Cc: [e-mail]
> Subject: Re: [AVT] Comments on draft-ietf-avt-ulp-11
> 
> 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.
> 
> Please find attached a document on this extension to RFC2733.
> 
> 
> 2) What is the rational behind the costraint a) in par.7.5?
> 
> I copy it here for your convenience:
> "     a. A media packet SHALL be protected only once at each
>              protection level higher than level 0. A media packet MAY be
>              protected more than once at level 0 by different packets,
>              providing the protection lengths of level 0 of these packets
>              are equal.
> "
> 
> This poses constraints on raised bits in masks for level>0. But perhaps it
> would
> be easier to let the user care and give an hint on the usefulness of the
> constraint...
> 
> --
> 
> I have also a couple of remarks.
> 
> 1) I was confused by reading in the introduction the following phrase:
> 
> "   Lower protection levels provide greater protection by using smaller
>        group sizes (compared to higher protection levels) for generating
>        the FEC packet.
> "
> 
> "Lower protections levels" made me think about a low protection but then I
> read
> "greater protection". The contradiction (low or great protection?)
> confused me.
> 
> Of course, this is a problem only for 1st time readers. However, it may be
> useful to rephrase as follows:
> 
> "   High priority levels provide greater protection ...
>        ... (compared to low priority levels ...
> "
> 
> Then, it can be specified that levels are numbered from hi-pri to low-pri
> starting from 0.
> 
> 
> 2) I appreciated the introduction and the reference to UXP.
> 
> I think you may find it useful to have a look at the attached
presentation,
> which compares several proposed FEC schemes: RFC2733, ULP, UXP, etc.
> 
> 
> Best regards,
> 
>       Andrea
> 
> --
>      ______________________________________________________________
> 
>       Andrea VITALI                            [e-mail]
> 
>       tel [phone]             mobile [phone]
>       fax [phone]
> 
>       STMicroelectronics
>       Centro Direzionale COLLEONI - Palazzo "DIALETTICA"
>       20041 Agrate Brianza (MI) ITALY
>      ______________________________________________________________
> 
> 




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