Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-report-extns-03.txt

From: [email-masked]
Date: Thu, 06 Mar 2003 10:42:26 -0500

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 Extended Reports (RTP XR)
	Author(s)	: T. Friedman et. al.
	Filename	: draft-ietf-avt-rtcp-report-extns-03.txt
	Pages		: 41
	Date		: 2003-3-5
	
This document defines the extended report (XR) packet type for the
RTP control protocol (RTCP).  XR packets are composed of report
blocks, and seven block types are defined here.  The purpose of the
extended reporting format is to convey information that supplements
the six statistics that are contained in the report blocks used by
RTCP's sender report (SR) and receiver report (RR) packets.  Some
applications, such as multicast inference of network characteristics
(MINC) or voice over IP (VoIP) monitoring, require other and more
detailed statistics.  In addition to the block types defined here,
additional block types may be defined in the future by adhereing to
the framework that this document provides.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-report-extns-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rtcp-report-extns-03.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-rtcp-report-extns-03.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.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Mar 2003 15:38:30 +0100

Hi,

I have some comments on the latest version of the draft. It starts to look good, and I hope for quick addressing of the problems. 

1. The title: I don't like the title, I think it is a bit miss leading. This is not a only RTP extended reports. Some of the things only are related to RTCP functionality. So maybe "RTP/RTCP Extended Reports" would be a better title.

2. The page length of the first page is different from the others. Maybe not that important as the RFC-Editor will change this page to be 1 line longer than all other pages in the draft. 

3. Section 1: Should be page break to a new page for readability.

4. The page header is not the normal one. See draft-rfc-editor-rfc2223bis-04.txt section 3.3. In drafts that results in the following example from above draft:

Internet-Draft        Instructions to RFC Authors            10 Feb 2003 

5. Section 1, bullet list with report blocks: All bullets with second lines should be indented to look nicer and be more readable. 

6. Section 2, Figure: The "PT=XP=207" shouldn't that be PT=XR=207?

7. Section 4.1, listing for format figure: The bullet for "SSRC of Source" is missing in the list. 

8. Section 4.3, The RTP Timestamp i, bullet after format figure: I still think that this format should be reduced. I also think there is a problem of using the RTP timestamp clock to stamp arrival time. First it is unnecessary as there is no connection between used RTP TS in the packet and the arrival sampling. Secondly, this section does not describe how you handle changes of RTP TS rates due to change of PT in the incoming data. It is also possible that different sources uses different RTP TS rates due to usage of different PTs. All these problems go away if one defines a single clock rate to use in this format. One can also then consider that the number of bits per report can be reduced significantly. 

9. Section 4.4 first paragraph. Why is not the TTL fields defined for the IPv6 Hop Limit field which is identical to TTL?

10. Section 4.4, The statistics summary format: I have earlier had the misconception that this format would actually be a bit smarter and having variable fields present. However I know understand that even if only a single part of the report is used the whole 40 bytes must be sent. I would be more efficient to remove the parts of the format that are not being reported on. I don't see the little complexity of such an operation as having much significance. If for example only a single part, e.g. TTL, of the block is of interest the overhead could be reduced with up to 24 bytes. 24 bytes may be as much as 20 % increase in packet size, i.e. the reporting interval could be reduced with the same amount. 

11. Section 4.4, The definition of standard deviation fields. All fields seems to be defined as they are integer fields why standard deviation calculations normal generate a real value. I think one needs to mention what type of operation is used to produce the integer value, rounding, ceiling, flooring?

12. Section 4.5 First sentence: Please include NTP in this sentence so that it reads: "This block extends RTCP's timestamp reporting so that non-senders may also send NTP timestamps.". This makes it clears directly what type of timestamp is used. 

13. Section 4.5 Last sentence of NTP timestamp definition: If a sender has no notion of time it shall not send this format at all. It is very unnecessary for other entities to waste bits on something no one can use. So I would suggest that the last sentence is changes to: "A report sender that has no notion of wallclock or elapsed time SHALL NOT send this report block.".

14. Section 4.6, block length definition: I think one should clarify that the length is used to derive the number of sources that are reported on in the reporting block. The formula seems to be as simple as taking "block length / 3". 

15. Section 4.6, Format definition: For completeness please include the SSRC_i in the fields explained. 

16. Section 4.6, DLRR definition: I think that senders of this block SHALL only send reports on sources sending the NTP Timestamp report. It is useless to spend bits on source that has not asked for this information. It is a total waste as the SSRC being reported has nothing to calculate the RTT unless it has sent a NTP Timestamp reporting block. I would also make a an addition to this paragraph that a reporter may stop reporting on a source after sending three times on the same LRR. A proposed text: 

"A Sender of DLRR reports MAY stop sending them for any given source when it has reported three times on the same LRR for that source. It MUST resume the reporting when it receives a new LRR in the form of a Receiver Timestamp Report block from that source."

17. Section 4.7.4: The signal level calculations are not clear as Log10 has been separated into "log 10". 

18. Section 4.7.7: How does one use the jitter buffer sizes when one has a sample based codec and have no defined frame size, or for that matter if the frame size is variable? 

19. Section 5: The first sentence, replace RTP with RTCP. 

20. Section 5.1: I don't think one can order IANA to give one a certain number. So I think changing SHALL to request is better. However this the chairs may answer better. 

21. Section 5.2: I think this format should register 255 as reserved for future extending of the number space. 

22. Section 5.2, last paragraph: I don't see much reason for the recommendation that 0 and 255 should not be used. There are several ways of checking integrity of the different reports. The simplest is to check the XR report block length against the different report blocks length field. This is simply a continuation of what should be performed at RTCP packet types level. I would in fact recommend that a new section containing decoding considerations is written to explain these method. 

23. Section 6: Second and third paragraph: Can we actually write something about the AS's right to keep network topology and characteristics confidential? 

24. Section A.1: Why is the extended sequence number initiated to the middle of the space? Normally one would start with an extended sequence number of 0. Shouldn't one try to be consistent with extended highest sequence number received in the receiver reporting. 

25. A SDP section. I still think that a SDP section should be included in this document. However if the authors of XR format draft are not willing to include it in their document, I volunteer myself to write and drive a separate SDP draft towards and RFC. 

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: [email-masked]

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

---

From: Timur Friedman <[email-masked]>
Date: Mon, 24 Mar 2003 23:28:03 +0100

Magnus Westerlund wrote :
> 24. Section A.1: Why is the extended sequence number initiated to the
> middle of the space? Normally one would start with an extended sequence
> number of 0. Shouldn't one try to be consistent with extended highest
> sequence number received in the receiver reporting.

For the detailed packet traces, reported upon by the Loss RLE blocks defined 
in the RTCP Extended Reports draft, we wish to make as few assumptions as 
possible regarding the packets that are observed.

In particular, we wish to avoid making the assumptions made for basic RTCP: 
for instance, that a certain number of packets must be received in order for 
a source to be considered valid, or that a certain number of packets must be 
received in order to consider that a large jump in sequence numbers has 
occurred.  These assumptions aid the functionality of RTCP, helping avoid 
errors in the receiver count, for instance.  But they might mask the sort of 
anomalous events that one would wish to catch with extended reports.

To address the particular question raised above, it is entirely possible that 
the sequence numbers could jump backwards.  This could result in rollover in 
the 16-bit RTP sequence number space.  To avoid rollover in the larger 32-bit 
extended sequence number space, we suggest starting roughly in the middle of 
that space.

- Timur Friedman