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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Dec 2006 11:35:04 +0100

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 +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: lazzaro <[email-masked]>
Date: Mon, 18 Dec 2006 09:15:00 -0800

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.

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

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