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

[Magnus Westerlund <[e-mail]>]

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.


2. The timestamp report block results in extremely large reports I think 
the block would much more useful if it default contains a less bandwidth 
using scheme for reporting the timestamps. My proposal is to change the 
format to the following.

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=3      | rsvd. |   T   |         block length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      First RTP timestamp and base             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Variable length encoded diff 1| diff 2        | Diff 3 ...    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


My idea is to take the first packet reception timestamp as is to form a 
base. Then for each following packet only the delta timestamp value from 
the previous packet is included. To save bytes this values is then 
encoded as one, two, three or four octets. This would in most case allow 
for reducing this block with 50% or more. At the same time the operation 
is not that complex and does not require substantial amount of 
processing. to end up on the next 32 bit boundary padding is required. 
This padding is easy to find as the number of reports are indicated with 
initial and last sequence number of the packets and the thinning factor.

A simple variable length encoding would be:
0-127         1 byte with first bit = 0, i.e. 0xxxxxxx
128-16383     2 bytes in the form 0xxxxxxx1xxxxxxx
16384-2097151 3 bytes in the form 0xxxxxxx1xxxxxxx1xxxxxxx
2097151-268435455 4 bytes in the form 0xxxxxxx1xxxxxxx1xxxxxxx1xxxxxxx

As this clock is running at the media clocks used it will have rates 
from 1000 up to 90000 in most case. For most packet rates that will mean 
that the diff between each packet will fit into a 2 byte value instead 
of four, reducing the necessary block size with almost 50 %. I assume 
that there are smarter variable encoding. So please propose anything 
that works better.

Best Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



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