Subject: [AVT] Re: I-D ACTION:draft-xie-avt-forward-shifted-red-00.txt

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Jan 2007 14:10:57 +0000

Qiaobing,

On 2 Jan 2007, at 20:50, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Forward-shifted RTP Redundancy Payload Support
> 	Author(s)	: Q. Xie, J. Schumacher
> 	Filename	: draft-xie-avt-forward-shifted-red-00.txt
> 	Pages		: 13
> 	Date		: 2007-1-2
> 	
>    This document defines a simple enhancement to RFC 2198 to  
> support RTP
>    sessions with forward-shifted redundant encodings, i.e., redundant
>    data is sent before the corresponding primary data.  Forward- 
> shifted
>    redundancy can be used to conceal losses of a large number of
>    consecutive media frames (e.g., consecutive loss of seconds or even
>    tens of seconds of media).
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-xie-avt-forward-shifted- 
> red-00.txt

This seems to be another take on the problem discussed in your old  
anti-shadow draft. When that draft was released, I commented that  
it's not at all clear to me why you don't just send an additional  
time-offset RTP stream, listing it as an alternative in the SDP,  
rather than defining a new format. Bundling an anti-shadow stream  
with the original stream forces all clients to receive the anti- 
shadow protection, whether or not they need it, and makes it  
difficult for gateways to add/remove protection. This comment still  
seems relevant with the latest draft.

Colin

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

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 05 Jan 2007 16:02:48 -0600

Hi, Colin,

>>    This document defines a simple enhancement to RFC 2198 to support RTP
>>    data is sent before the corresponding primary data.  Forward-shifted
>> http://www.ietf.org/internet-drafts/draft-xie-avt-forward-shifted-red-00.txt 
>>
> 
> anti-shadow draft. When that draft was released, I commented that it's 
> not at all clear to me why you don't just send an additional time-offset 
> RTP stream, listing it as an alternative in the SDP, rather than 
> defining a new format. Bundling an anti-shadow stream with the original 
> stream forces all clients to receive the anti-shadow protection, whether 
> or not they need it, and makes it difficult for gateways to add/remove 
> protection. This comment still seems relevant with the latest draft.

Yes, you are right that this is an attempt to address the same problem 
in the old anti-shadow draft. It just occurs to us that this is a much 
cleaner and simpler way (by simply enabling forward shift in RFC 2198 
and nothing more) to achieve the same goal the old draft was trying to 
achieve.

As to the pros and cons of sending redundant data and primary data in 
the same RTP session, we are here trying to take a free ride on the same 
justification used to justify RFC 2198. No intention to expand or alter 
that at all (only change is to allow the time-shift in the forward 
direction).

In general, for using time-offset redundant data (both backward-shifted 
as in RFC 2198, or forward-shifted as in this proposed enhancement), the 
pros for sending it together with the primary data in a single RTP 
session including much simpler session setup and management, as well as 
easier NAT/firewall traverse.

Of cause, this or RFC 2198 does not preclude a deployment from using the 
alternative way of sending an additional time-offset RTP stream 
separately. But it does give the deployment the choose to send them 
together if it's deemed beneficiary under the circumstance.

regards,
-Qiaobing

---

From: Colin Perkins <[email-masked]>
Date: Sat, 6 Jan 2007 10:16:44 +0000

hi Qiaobing,

>>> A New Internet-Draft is available from the on-line Internet-Drafts
...
>> difficult for gateways to add/remove protection. This comment  
>> still seems relevant with the latest draft.
>
> Yes, you are right that this is an attempt to address the same  
> problem in the old anti-shadow draft. It just occurs to us that  
> this is a much cleaner and simpler way (by simply enabling forward  
> shift in RFC 2198 and nothing more) to achieve the same goal the  
> old draft was trying to achieve.

I agree that it's much better than the old proposal, although I'd  
much prefer it to be a new MIME types, rather than trying to add a  
new parameter to audio/red, since that would help ease negotiation,  
and reduce the backwards compatibility problems.

> As to the pros and cons of sending redundant data and primary data  
> in the same RTP session, we are here trying to take a free ride on  
> the same justification used to justify RFC 2198. No intention to  
> expand or alter that at all (only change is to allow the time-shift  
> in the forward direction).
>
> In general, for using time-offset redundant data (both backward- 
> shifted as in RFC 2198, or forward-shifted as in this proposed  
> enhancement), the pros for sending it together with the primary  
> data in a single RTP session including much simpler session setup  
> and management, as well as easier NAT/firewall traverse.
>
> Of cause, this or RFC 2198 does not preclude a deployment from  
> using the alternative way of sending an additional time-offset RTP  
> stream separately. But it does give the deployment the choose to  
> send them together if it's deemed beneficiary under the circumstance.

Sure, but some discussion of the trade-off, advantages and  
disadvantages of the two approaches, should be in the draft.

Colin

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 09 Jan 2007 11:26:21 -0600

Hi, Colin,

...
> I agree that it's much better than the old proposal, although I'd much 
> prefer it to be a new MIME types, rather than trying to add a new 
> parameter to audio/red, since that would help ease negotiation, and 
> reduce the backwards compatibility problems.

That would be fine with me. Will update the draft to use a new MIME type 
in the next revision.

>> the same RTP session, we are here trying to take a free ride on the 
>> same justification used to justify RFC 2198. No intention to expand or 
>> alter that at all (only change is to allow the time-shift in the 
>> forward direction).
>>
>> In general, for using time-offset redundant data (both 
>> backward-shifted as in RFC 2198, or forward-shifted as in this 
>> proposed enhancement), the pros for sending it together with the 
>> primary data in a single RTP session including much simpler session 
>> setup and management, as well as easier NAT/firewall traverse.
>>
>> Of cause, this or RFC 2198 does not preclude a deployment from using 
>> the alternative way of sending an additional time-offset RTP stream 
> Sure, but some discussion of the trade-off, advantages and disadvantages 
> of the two approaches, should be in the draft.

Ok, I will add this discussion in the next revision as well.

Thanks for the good suggestions

regards,
-Qiaobing