Subject: RE: [AVT] Working group last call: draft-ietf-avt-rtp-amr-bis-04.txt

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 10 Jul 2006 10:29:46 -0700

Comments on Section 8.3.2

- The usage of "max-red" puts a global upper limit on the usage of
       redundancy that needs to be followed by all that understand the
       parameter. However due to the late addition of this parameter, it
       may be ignored by some implementations

It would be nice to have few lines which describe the impact on existing
implementations which do not understand this parameter? If there is no
impact, it would be better to say so

It would be nice to see few lines which can motivate (with a use-case)
an existing implementation to be upgraded to understand "max-red"

Is there a recommended value range for "max-red" which the authors think
should be most commonly used? Any hints to implementers on what
(default) value to choose under what conditions?

Comments on MIME registrations:

max-red: A by the sender guaranteed maximum duration in
                milliseconds that elapse between the primary (first)
                transmission of a frame and any redundant transmission

Definition of "max-red" in both MIME registrations starts with "A by the
sender"? That looks like a typo there!

--Hari

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Thursday, June 29, 2006 8:47 AM
> To: AVT WG
> Subject: [AVT] Working group last call:
draft-ietf-avt-rtp-amr-bis-04.txt
> 
> This is to announce a working group last call on the RTP Payload
> Format and File Storage Format for AMR and AMR-WB audio codecs.
> Please send any final comments to the mailing list by 21st July 2006.
> If there are no issues are raised, we will request the IESG consider
> this for publication as a Proposed Standard RFC, to obsolete RFC 3267.
> 
> Colin
> 
> 
> 
> On 27 Jun 2006, at 20:50, [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Audio/Video Transport Working
> > Group of the IETF.
> >
> > 	Title		: RTP Payload Format and File Storage Format
> >                           for the Adaptive Multi-Rate (AMR) and
> >                           Adaptive Multi-Rate Wideband (AMR-WB)
> > Audio Codecs
> > 	Author(s)	: J. Sjoberg, et al.
> > 	Filename	: draft-ietf-avt-rtp-amr-bis-04.txt
> > 	Pages		: 58
> > 	Date		: 2006-6-27
> >
> > This document specifies a real-time transport protocol (RTP) payload
> > format to be used for Adaptive Multi-Rate (AMR) and Adaptive
> > Multi-Rate Wideband (AMR-WB) encoded speech signals.  The payload
> > format is designed to be able to interoperate with existing AMR and
> > AMR-WB transport formats on non-IP networks.  In addition, a file
> > format is specified for transport of AMR and AMR-WB speech data in
> > storage mode applications such as email.  Two separate media type
> > registrations are included, one for AMR and one for AMR-WB,
> > specifying use of both the RTP payload format and the storage
> > format. This document obsoletes RFC 3267.
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-bis-04.txt
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Jul 2006 14:21:51 +0200

Thanks for the feedback.

> impact, it would be better to say so

Yes, that can be added. Some of this is discussed in the offer/answer 
section using the following text:
             "As this parameter was not
              defined orignally some senders will not declare this
              parameter even if it will limit or not send redundancy at
              all."

We have probably not included this in the other direction due to the 
fact that it simply will be ignored as defined initially in the media 
types definition of RFC 3267:

"Note, any unspecified parameter MUST be ignored by the receiver."

With the addition in this specification that an unknown parameter shall 
also not be included in the reply there should be no ill effects. Please 
remember that RFC 3267 clearly specifies that it is required to have the 
capability to handle duplication of frames. Thus this signalling only 
allows for optimization and indication of cases when it is not providing 
any benefit of transmitting redundant frames.

See below for an addition in the changes section to this.

> an existing implementation to be upgraded to understand "max-red"

The main benefit is the possibility to define the maximum extra delay 
needed in the receiver to be able to fully utilize the redundant data. 
It also allows a sender to indicate that no redundancy will be used. If 
not implemented a receiver needs to be adaptive to the amount of 
redundancy or simply ignore any late arriving redundant data.

I propose to update the changes section to the following:

"-	Added a media type parameter "max-red" that allows the sender to 
declare a bounded usage of redundancy. This parameter allows a receiver 
to operate more optimized as it will know if redundancy will may be used 
or not. And if used, the maximum extra delay it will require to be fully 
utilized in the receiver. The addition of this parameter should have no 
negative effects on older implementations as they are mandated to ignore 
unknown parameters per RFC 3267. And in addition are required to operate 
as if the value of max-red is unknown and possibly infinite."

I hope this is clear enough without a full use-case description.

> (default) value to choose under what conditions?

The problem here is that it depends on the application. In a conversational
case it might be restricted to a few frames due to the introduced delay. 
Thus I think
2-3 frames would be most likely to be used. In a streaming or other more 
delay tolerant usage the value could be substantially larger. Therefore 
I hesitate to include any values. Please remember that including no 
value means that this parameter is in fact set to infinity. As it is the 
sending side that declare this value it should be easy for the 
implementations to declare a value they feel comfortable being 
restricted with. If one will not use redundancy at all, one really 
should set 0. I think the last is the only real solid advice I can give. 
And that is present in the offer/answer section.

> sender"? That looks like a typo there!
No, it is not a typo. But maybe should be changed to:

The maximum duration in milliseconds that elapse between the primary 
(first)transmission of a frame and any redundant transmission that the 
sender will use.

Is that better?

Cheers

Magnus Westerlund

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]

---

From: Colin Perkins <[email-masked]>
Date: Thu, 27 Jul 2006 22:44:00 +0100

Okay, so we'll wait for the -05 draft, then re-issue a new working  
group last call.

Colin

On 27 Jul 2006, at 13:21, Magnus Westerlund wrote:

> Yes, that can be added. Some of this is discussed in the offer/ 
> answer section using the following text:
> We have probably not included this in the other direction due to  
> the fact that it simply will be ignored as defined initially in the  
> media types definition of RFC 3267:
>
> With the addition in this specification that an unknown parameter  
> shall also not be included in the reply there should be no ill  
> effects. Please remember that RFC 3267 clearly specifies that it is  
> required to have the capability to handle duplication of frames.  
> Thus this signalling only allows for optimization and indication of  
> cases when it is not providing any benefit of transmitting  
> redundant frames.
>
> The main benefit is the possibility to define the maximum extra  
> delay needed in the receiver to be able to fully utilize the  
> redundant data. It also allows a sender to indicate that no  
> redundancy will be used. If not implemented a receiver needs to be  
> adaptive to the amount of redundancy or simply ignore any late  
> arriving redundant data.
>
> declare a bounded usage of redundancy. This parameter allows a  
> receiver to operate more optimized as it will know if redundancy  
> will may be used or not. And if used, the maximum extra delay it  
> will require to be fully utilized in the receiver. The addition of  
> this parameter should have no negative effects on older  
> implementations as they are mandated to ignore unknown parameters  
> per RFC 3267. And in addition are required to operate as if the  
> value of max-red is unknown and possibly infinite."
>
> case it might be restricted to a few frames due to the introduced  
> delay. Thus I think
> 2-3 frames would be most likely to be used. In a streaming or other  
> more delay tolerant usage the value could be substantially larger.  
> Therefore I hesitate to include any values. Please remember that  
> including no value means that this parameter is in fact set to  
> infinity. As it is the sending side that declare this value it  
> should be easy for the implementations to declare a value they feel  
> comfortable being restricted with. If one will not use redundancy  
> at all, one really should set 0. I think the last is the only real  
> solid advice I can give. And that is present in the offer/answer  
> section.
>
>
>
>
> The maximum duration in milliseconds that elapse between the  
> primary (first)transmission of a frame and any redundant  
> transmission that the sender will use.
>
> Is that better?
>
> Cheers
>
> Magnus Westerlund
>

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 27 Jul 2006 15:45:20 -0700

> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Thursday, July 27, 2006 5:22 AM
> To: Desineni, Harikishan
> Cc: AVT WG; Colin Perkins
> Subject: Re: [AVT] Working group last call: 
> The main benefit is the possibility to define the maximum 
> extra delay needed in the receiver to be able to fully 
> utilize the redundant data. 
> It also allows a sender to indicate that no redundancy will 
> be used. If not implemented a receiver needs to be adaptive 
> to the amount of redundancy or simply ignore any late 
> arriving redundant data.
> 
> declare a bounded usage of redundancy. This parameter allows 
> a receiver to operate more optimized as it will know if 
> redundancy will may be used or not. And if used, the maximum 
> extra delay it will require to be fully utilized in the 
> receiver. The addition of this parameter should have no 
> negative effects on older implementations as they are 
> mandated to ignore unknown parameters per RFC 3267. And in 
> addition are required to operate as if the value of max-red 
> is unknown and possibly infinite."
> 

[Hari]I am not sure if the "changes section" continues to stay at the
time this draft becomes an RFC. It would be nice to have this
clarification in a real section in the draft/RFC. 

In case of conversational service the redudancy delay introduced at the
sender may not show up exactly at the receiver. i.e., the receiver might
still have to adapt a bit to the varying delay in receiving the
redundant packets. Hence, I feel like changing "maximum extra delay" to
"approximate value of maximum extra delay" would make more sense here.

I am OK with all other changes you proposed.
- - - - - - - - - - - - - - - - - -
Harikishan Desineni
Qualcomm Inc.,
mailto:[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Jul 2006 09:22:13 +0200

> clarification in a real section in the draft/RFC. 

As this is an RFC obsoleting another the changes section in regards to 
the previous RFC will stay.

> "approximate value of maximum extra delay" would make more sense here.

Okay, I would rather clarify it in the following way as "appropriate" 
can be misinterpreted.

"And if used, the maximum extra delay introduced by the sender that is 
needed to be considered by the receiver to fully utilize the redundancy."

Is that better?

Cheers

Magnus Westerlund

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 28 Jul 2006 09:56:37 -0700

> Sent: Friday, July 28, 2006 12:22 AM
> To: Desineni, Harikishan
> >> receiver to operate more optimized as it will know if 
> redundancy will 
> >> may be used or not. And if used, the maximum extra delay it will 
> >> require to be fully utilized in the receiver. The addition of this 
> >> parameter should have no negative effects on older 
> implementations as 
> >> they are mandated to ignore unknown parameters per RFC 
> 3267. And in 
> >> addition are required to operate as if the value of max-red is 
> >> unknown and possibly infinite."
> >>
> As this is an RFC obsoleting another the changes section in 
> regards to the previous RFC will stay.

OK.

> 
> > 
> > In case of conversational service the redudancy delay introduced at 
> > the sender may not show up exactly at the receiver. i.e., 
> the receiver 
> > might still have to adapt a bit to the varying delay in 
> receiving the 
> > redundant packets. Hence, I feel like changing "maximum 
> extra delay" 
> > to "approximate value of maximum extra delay" would make 
> more sense here.
> 
> "And if used, the maximum extra delay introduced by the 
> sender that is needed to be considered by the receiver to 
> fully utilize the redundancy."
> 
> Is that better?

Yes.