RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt

["Timur Friedman" <[e-mail]>]

Hello Magnus,

[I address the signalling in this mail, and the timestamp block in a
subsequent mail.]

Getting a handle on the signalling for RTP XR reports is a major
priority.  Thank you for taking the initiative to think through how it
might be done.

I wonder, though, if it would be alright if we were to submit this as a
subsequent draft.  The concern is that introducing a significant change
at this point would make it difficult to proceed to working group last
call at San Francisco.

If not having signalling means we should not propose a standard then of
course we should wait.  But to my mind the extended reports are useful
in themselves, and a proposed standard will allow important work to go
forward.

Part of this work will entail applications that deploy these reports.
With the experience gained, we may be in a better position to say
exactly how signalling should be done than we are now.

Best regards,

Timur

-----Original Message-----
From: Magnus Westerlund [mailto:[e-mail]] 
Sent: Thursday, February 20, 2003 11:17 AM
To: Timur Friedman
Cc: [e-mail]
Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt

Hi Timur,

I have in the last few weeks come to some insight on where I desire to 
use some of the reporting blocks. Therefore I have two general comments 
on what I would in fact like to add to the XR format:

1. I would like to add SDP signaling to the draft. In the use case of 
streaming when only the server sends media to the client there is no 
need for the server to send XR report blocks of other types then 
responses to RTT measurements. However the server may very much desire 
to receive the XR formats. However some other servers may not support 
the XR format and then it would be waste of bandwidth. Therefore I see a

need for allowing the server to ask the client to send XR reports and 
which formats it is interested in.

It also seem to be interesting to have the recipient ask for what 
thinning factor it would like to see. Also the reporting overlap between

each packet, i.e. should each packet report on the new data from last 
report and also how many already reported packets. All this is of course

only recommendations to the send of the XR packet. They may need to 
reevaluate the request based on bandwidth consumption etc.

This is my motivation therefore I propose the following SDP parameter 
chapter to be included in the draft:
----------------------------------

x SDP Signaling for the XR Format

To allow the recipient of  XR format to specify what format it would 
like to receive the following media level SDP attribute is defined. If 
included in a SDP media block the recipient of the SDP is RECOMMENDED to

send RTCP XR reports containing the report blocks indicated in the 
attribute. To allow the recipient to also direct the sender of XR 
reports on what configuration it desires on each block some parameters 
are also possible to define for each report block type. These are also 
only recommendations to the sender and MAY be ignored due to other 
considerations. Such other considerations is for example, complexity of 
gathering the information, and the bandwidth usage imposed by the
reporting.

The SDP attribute is defined as following in ABNF of RFC 2234

XR-attriute = "a" "=" "rtcp-xr" ":" xr-format *(";" xr-format) CRLF
xr-format = loss-rle-def
          / dupp-rle-def
          / timestamp-def
          / stat-sum-def
          / rcv-time-RTT-def
          / DLRR-def
          / VOIP-metrics-def
          / extension-type

loss-rle-def  = "loss-rle" "=" overlap "/" thinning-factor
dupp-rle-def  = "dupp-rle" "=" overlap "/" thinning-factor
timestamp-def = "rcv-time" "=" overlap "/" thinning-factor
stat-sum-def  = "stat-sum" "=" loss-flag "/" dupp-flag "/" jitt-flag "/"

TTL-flag
loss-flag = boolean     ; Include loss block
dupp-flag = boolean     ; Include duplicate block
jitt-flag = boolean     ; Include jitter block
ttl-flag  = boolean     ; Include TTL block
boolean = "0" / "1"     ; False or True
rcv-time-RTT-def = "rcv-rtt" "=" boolean
DLRR-def      = "dlrr" "=" boolean
VOIP-metrics-def = "voip" "=" "1"
extension-type = token "=" Value *("/" Value)
Value = token / quoted-stirng
overlap = 1*DIGIT          ;
thinning-factor = 1*2DIGIT  ; 0-15 is valid values

The "overlap" factor tells the sender of reports how many reporting 
intervals the statistics should cover. A overlap factor of 0 means only 
information gathered since the last report using this format. An overlap

factor of 1 would mean that the reporter should send information 
gathered both since the last sent report and the previous sent report 
packet.

The thinning factor is the value the reporter should use in its report. 
It is defined for each of the report blocks that has this value and 
valid values are 0-15.

The "stat-sum" parameter contains boolean flags (0 or 1) for each of the

four parts that can be included in this packet. The "stat-sum" parameter

SHOULD NOT be included unless at least one of the block flags are true, 
i.e. signaling inclusion of some block.

The "rcv-rtt" parameter tells the receiver of this SDP if it can use the

block or not within the session. By including this parameter with a true

value the source of the SDP indicates that it will respond using the 
DLRR report block and that it is meaningful to send Receiver Timestamp 
Report Block. This parameter is useful for servers or multicast senders 
to indicate its support for allowing the receiver to measure the RTT. It

is always the receivers choice to send Receiver Timestamp Report blocks.
 
The "dlrr" parameter indicates by its value of true or false if the 
reporter SHOULD answer Receiver Timestamp report blocks it receives 
using the DLRR report block. This allows a multicast session sender to 
recommend the receiver of the session to not waste RTCP bandwidth on RTT

measurements.

The presence of the "voip" parameter indicates that the reporter is 
RECOMMENDED to include the report block in the RTCP XR format. It has a 
hard coded value to simplify parsing as all parameters have the 
structure <parameter name> = <values>

This format is extensible as new report blocks are included. Recipients 
of the SDP attribute SHOULD ignore any unknown parameters by skipping to

past the next ";" or if non present to the end of line.

-----------------------------------
A IANA repository needs to be established for this SDP attribute to 
enable future extensions. The same rules that applies to registering XR 
report blocks apply to registering new attribute parameters.

...


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