Subject: [AVT] I-D ACTION:draft-ietf-avt-avpf-ccm-05.txt

From: [email-masked]
Date: Mon, 14 May 2007 15:50:02 -0400

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		: Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
	Author(s)	: S. Wenger, et al.
	Filename	: draft-ietf-avt-avpf-ccm-05.txt
	Pages		: 66
	Date		: 2007-5-14
	
This document specifies a few extensions to the messages defined in
   the Audio-Visual Profile with Feedback (AVPF).  They are helpful
   primarily in conversational multimedia scenarios where centralized
   multipoint functionalities are in use.  However some are also usable
   in smaller multicast environments and point-to-point calls.  The
   extensions discussed are messages related to the ITU-T H.271 Video
   Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit
   Rate and Temporal Spatial Trade-off.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-avt-avpf-ccm-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-avpf-ccm-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 May 2007 10:48:43 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-05.txt

Hi,

Like the previous version this contains the updated TMMBR version, 
expressed as maximum available bit-rate at layer X and the amount of 
overhead per packet from the RTP payload down to the header of layer X. 
Where layer X is the layer the receiver selects to report on. However 
the explanation, the definitions, the algorithm are all rewritten. A 
large thanks to Tom Taylor for helping us with this clean up. So you who 
participated in the 100+ message thread on this solution. Please review it.

The document also contains a number of smaller changes and fixes to make 
it ready for publication. We have fixed, things like IANA registration, 
use of example IP ranges, cleaned up introduction to make it easier to 
read and language fixes.

A diff from the previous version may not be the most help due to the 
large number of changes to the text. But for the ones interested here is 
one (as soon as the tools pages has been updated):
http://tools.ietf.org/wg/avt/draft-ietf-avt-avpf-ccm/draft-ietf-avt-avpf-ccm-05-from-04.diff.html

So please take a look at it so we can determine if we are ready to go 
forward or not.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Franceschini Guido" <[email-masked]>
Date: Tue, 15 May 2007 14:40:29 +0200

Magnus,

I read the new draft, which really looks improved. I noticed what I interpreted as a mistake in the following sentence in 3.5.4.2

"Note that the slopes of the lines making up the bounding polygon are  
increasingly negative as one moves in the direction of increasing  
packet rate."

I think that you meant 'per packet overhead' in place of 'packet rate'.

Finally, the message syntax partitions a 32 bit word into:
- 6  bits (MxTBR Exp)
- 17 bits (MxTBR Mantissa)
- 9  bits (Measured Overhead)

I would have chosen 8-16-8, or even 2(reserved)-6-16-8.

Best regards
Guido

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: martedì 15 maggio 2007 10.49
To: [email-masked]
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-avpf-ccm-05.txt

Hi,

Cheers

Magnus Westerlund

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

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 15 May 2007 08:57:15 -0400

On that first comment: the X-axis of the figure is indeed packet rate. Please 
see the label on the axis in Figure 1.

---

From: "Franceschini Guido" <[email-masked]>
Date: Tue, 15 May 2007 15:12:56 +0200

Actually I mis-interpreted the sentence.
I had in mind that it was stating that the higher the per-packet overhead is, the bigger the slope.
Now I understand the meaning of the description, which is OK.

Sorry for my mistake.
Guido

-----Messaggio originale-----
Da: Tom-PT Taylor [mailto:[email-masked]] 
Inviato: martedì 15 maggio 2007 14.57
A: Franceschini Guido
Cc: Magnus Westerlund; [email-masked]
Oggetto: Re: [AVT] I-D ACTION:draft-ietf-avt-avpf-ccm-05.txt

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 May 2007 15:23:00 +0200

Thanks

For looking at the draft so quickly.

> I would have chosen 8-16-8, or even 2(reserved)-6-16-8.

Well, this is an attempt to be certain that we have enough room for the 
future in the fields. I think 256 bytes of overhead is on the border of 
being sufficient. To be certain that we don't run into problems when 
there are tunnels in tunnels and things like that I like to keep 9 bits 
for the overhead to enable up to 511 bytes of overhead being 
represented. We clearly don't need more bits for the exponent as it 
already today allows for values 2^63*mantissa which currently allows for 
10^24 bits per second. However removing a bit would be to little as we 
would be limited to 4,2 GB * mantissa. And I do want to have a large 
mantissa as possible.

To me the extraction of the fields doesn't seem to me to be a 
performance bottleneck in the usage of TMMBR. We don't expect there to 
be thousands of messages per second of these. So the very minor (if any) 
difference in reading aligned 8-bit fields compared to totally 
non-aligned fields doesn't matter.

Cheers

Magnus Westerlund

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 21 May 2007 06:04:53 -0700

Few comments on -05

Comment 1:
As stated in 2.2, maximal media bit-rate is not a measured value.
The terminology is somewhat vague in sec 4.2.1.2. The word "observed" is
used for maximal media bit-rate (first item in TMMBR message). The word
"measured" is (correctly) used for the header overhead. Readers might
misinterpret the word "observed" as "measured", while reading 4.2.1.2. I
suggest using "available at a receiver chosen protocol layer"

Comment 2:

In sec 3.5.4.2 and figure 1, the Y-axis should be clarified as "Net
Media bit-rate". 

Comment 3: 
What happens when the most limiting restriction is a sender's uplink? In
this case it would be better for TMMBN to carry a new tuple capturing
its uplink max bit-rate restriction. This could suppress several TMMBRs
from receivers whose maximal media bit-rates are above the restriction
notified by the sender.

--Hari

> Sent: Tuesday, May 15, 2007 1:49 AM
> To: [email-masked]
> > 	Title		: Codec Control Messages in the RTP Audio-Visual
Profile
> with Feedback (AVPF)
> participated in the 100+ message thread on this solution. Please
review
> it.
http://tools.ietf.org/wg/avt/draft-ietf-avt-avpf-ccm/draft-ietf-avt-avpf
-
> ccm-05-from-04.diff.html

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 May 2007 15:46:26 +0200

> suggest using "available at a receiver chosen protocol layer"

Okay

> In sec 3.5.4.2 and figure 1, the Y-axis should be clarified as "Net

Yes, that is correct.

> from receivers whose maximal media bit-rates are above the restriction

Yes, to suppress the sending of TMMBR messages the media sender itself 
could send a TMMBR to itself to establish a limitation. I guess there is 
  a point to provide a comment that explains that media senders may 
themselves limit the bit-rate temporarily beyond what session 
establishment signalling have.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Tue, 29 May 2007 10:19:41 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-05.txt

Some minor comments on this (sorry Magnus - I realise you just  
submitted -06!)

Section 1.1 (last paragraph): suggest changing "Finally, all  
messages..." to "Finally, and most importantly, all messages..."

Section 3 is specified as being Informative, but is referenced in a  
normative manner from Section 4 (for the description of the TMMBR  
algorithm). Should maybe remove "(Informative)" from the title of  
Section 3?

Section 4.1: shouldn't the reference to RFC 4587 be to the old H.261  
format, since it's talking about the old back-channel messages (which  
were removed in the update)? (also in section 4.3.1.1 half way down  
page 46)

Section 4.1 (bottom of page 34): maybe note that use for other  
purposes is inappropriate?

Section 4.3.4.2: Table 2 missing > sign in -06 draft (also, -06 has  
some weird formatting problems, with lines split oddly on section  
cross-references?)

References: [Topologies] should be informative? idnits complains

Otherwise looks good.

Cheers,
Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 May 2007 17:06:49 +0200

Colin Perkins skrev:
>> Profile with Feedback (AVPF)
> Some minor comments on this (sorry Magnus - I realise you just submitted 
> -06!)
> 

Good suggestion.

> algorithm). Should maybe remove "(Informative)" from the title of 

Yes, I will simply remove it.

> were removed in the update)? (also in section 4.3.1.1 half way down page 
> 46)

Yes, it should. I think it is a result of not thinking enough when using 
ID-nits and the implication of updating the reference.

> 
> Section 4.1 (bottom of page 34): maybe note that use for other purposes 
> is inappropriate?

Yes, but in fact I think we can write something like the below which 
also covers the previous bullet list with rationales.

"Messages that are not fulfilling the above listed rationales are not 
appropriate to be defined to use with RTCP and in the Codec Control 
Framework defined in this document."

> 
> Section 4.3.4.2: Table 2 missing > sign in -06 draft (also, -06 has some 
> weird formatting problems, with lines split oddly on section 
> cross-references?)
> 

Not in the version I download from the IETF repository or the version I 
have locally on my disk.

Yes, I have had some problem with using Word. It inserts a number of 
spurious spaces or tabs before cross references.

> References: [Topologies] should be informative? idnits complains

Fixed.

Please comment on the suggested text for section 4.1.

Cheers

Magnus Westerlund

---

From: Tom Taylor <[email-masked]>
Date: Wed, 30 May 2007 16:03:33 -0400

A slight adjustment of your suggested text. How about:

"Messages that do not conform to the design principles just described 
are not an appropriate use of RTCP or of the Codec Control Framework 
defined in this document."

> Colin Perkins skrev:
...
> Framework defined in this document."
...

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 31 May 2007 10:53:50 +0200

> defined in this document."

Yes, that was better. Unless anyone protest I will aim to submit a new 
version at the end of the day.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Thu, 31 May 2007 10:23:20 +0100

On 31 May 2007, at 09:53, Magnus Westerlund wrote:
>> "Messages that do not conform to the design principles just  
>> described are not an appropriate use of RTCP or of the Codec  
>> Control Framework defined in this document."
>
> Yes, that was better. Unless anyone protest I will aim to submit a  
> new version at the end of the day.

Fine with me.

Cheers,
-- 
Colin Perkins
http://csperkins.org/