[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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 +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt