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

[lazzaro <[e-mail]>]

On Dec 18, 2006, at 2:35 AM, Magnus Westerlund wrote:

> 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.


All good points ...

Maybe the question is, is the right thing to do to
add your "real-world" view on these topics to the
I-D, or to just skip the topics entirely.  For newcomers,
there can be this information vacuum that comes
from reading RFCs and I-Ds and actually believing
them -- for example, a 1st-year grad student who reads the
2006-dated RFC 4566 SDP document might very well
believe that multicast transport is commonly used
on the public Internet in 2006.  A How-To RFC might
be the right place to add a snapshot of real-world usage
into the document series.


> 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]
> ----------------------------------------------------------------------

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---



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