[AVT] Comments on draft-ietf-avt-rtcp-report-extns-03.txt

[Magnus Westerlund <[e-mail]>]

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 [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