[AVT] Re: draft-ietf-avt-rtp-howto-01.txt

[Magnus Westerlund <[e-mail]>]

Hi John,
(CC AVT)

Thanks for the comments. I have incorporated the typos in my working 
copy. I do have some comments regarding a few of the items.


lazzaro skrev:
> Hi Magnus,
> 
> 	Comments on draft-ietf-avt-rtp-howto-01.txt below.
> 
> ---
> In 3.1.1, mention RFC Errata as a pragmatic way of
> disseminating small fixes.

Well, maybe. It is something that is worth checking. However in general 
it is a mechanism that hasn't be working. The RFC-editor hadn't until a 
month or so published more than a handful erratas in the last 1.5 years. 
Thus without a working Errata publication mechanism it isn't worth 
mentioning as something that works. Also despite its pragmatism too few 
people know about it. Thus even minor errors can be worth republishing 
an RFC for.

> 
> In 3.1.2, mention framing RTP over TCP as another
> robustness solution (with its own pros and cons).

Yes, for completeness I guess it should be mentioned. However it is not 
something that one should design towards, unless really, really 
necessary. In fact I think using HTTP or some other protocol on top of 
TCP may be a better way to handle data that can't handle losses at all 
then using RTP in between.

> 
> Somewhere in 3, mention UDP-lite and how certain
> payload formats may benefit by organizing its
> bitfields to be compatible with it.  Uneven FEC
> protection could also be fit in here.

Yes, however I think the verdict is still not in for this mechanism. So 
far I don't think anyone is really using it. The big issue is that you 
don't know if you have 10E-5 bit errors or if you have 100% error in the 
unprotected bits. Thus it makes designing for it very difficult. Despite 
being on the spearhead of this development with the AMR payload I today 
are very skeptic on its usefulness. Here the ULP may be slightly better. 
At least you have a known design target, which is 100% loss of 
unprotected bits.

> 6.1  Consider mentioning RTP MIDI's use of the
> recovery journal concept to drive payload-format
> specific resiliency for payload formats that
> carry time-stamped symbolic media representations.
> Also mention how it uses the Extended Highest
> Sequence Number Received in RTCP, and how
> other forms of resiliency might also want to use
> this field.
> 

I don't think we want to promote payload specific resilience to much due 
to the complexity it incurs. Only when absolutely necessary should it be 
used. But I guess one can't avoid these things in all cases.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
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