Subject: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-01.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Nov 2002 14:05:16 +0100

Hi,

I have some comments on the RTCP reporting extensions draft. They are 
rather many and if you don't understand my comments please ask:

1. Section 2: As draft-ietf-avt-rtcp-feedback has proposed that they 
will use RTCP PT 205 and 206, I would suggest that the XP packet type 
uses 207.

2. Section 2: Length  field explanation. Yes, the length field may 
contain a value 0 meaning a XP packet length of 4 bytes. However as the 
XP packet header without any reporting block will be 8 bytes the length 
field can only be 1 or larger for this packet type.

3. Section 2: Report blocks: In the explaining text it allows for a 
report block of 0 length. I think this is wrongly to state as any report 
block of zero length is no report block and no information is carried. 
The case of no report blocks are already covered in a previous sentence.

4. section 4.1: I think the section does not define what a packet loss 
is. Is a packet to late to be useful a packet loss. If not and packet 
loss is only packet never showing up then it should be mentioned that a 
old loss may change status to not lost if it arrives late.

5. Section 4.1 Definition of end_seq: What is the reason that the 
end_seq shall point on the packet after the last? It seams more logical 
for me to have a range specifiers that are inclusive in both ends.

6. Section 4.2: Why are the begin_seq and end_seq 32 bits field here, 
they should be only 16 bits and a whole 32 bit word can be saved.

7. Section 4.2 Definition of chunk: Please make explicit chapter 
reference to section 4.1 for the chunk definition.

8. Section 4.3: Begin_seq and end_seq are 32 bits where 16 bits are enough.

9. Section 4.3: RTP timestamp field: How shall one handle cases when the 
packet is lost and no receiver timestamp exists? I would suggest that 
one uses 0 as a lost indicator. In case a measured timestamp is 0 it 
should be increased with one millisecond to 1 to show a measurement was 
taken.

10. Section 4.4: begin_seq and end_seq are 32 bits where only 16 are useful.

11. Section 4.5: The report block should not have a 24 bit reserved 
field, instead a 16 bit length field with the value of 2 must be present 
in the rightmost 16 bits. Otherwise consistent parsing of report blocks 
are not possible.

12. Section 4.7.3: Burst metrics. They need better explanation and 
should reference the examples that are later in the chapter. Also the 
setting of the Gmin value should be explained and better specified. I 
think a more certain default value is needed.

13. Section 4.7.3 Burst duration: The meaning of burst intervals are not 
100% clear. A burst interval is in my opinion the distance between the 
beginning of one burst and the next. However in this definition it seems 
to indicate the individual bursts.

14. Section 4.7.3: The burst example. Is the burst really that long for 
a Gmin = 4. The last loss indicated in the burst has four received 
packets to the left and whole bunch to the right of it. According to 
what I understand of the definition that loss would not be part of a 
burst. I also does not understand how you can derive a GAP duration of 
510 ms for that example.

15. Is the mean a really good value to measure? It gives less and less 
indication of changes as the session progress. May it not be better to 
define these values as a simple IIR filter similar to the definition of 
the RTCP RR jitter value (jitter = 1/16*new_value + 15/16*jitter)?

16. Section 4.7.5 Double talk level:  What  frames can be considered to 
contain speech in comparison to background noise? What mechanism should 
be used to determine the difference? Not all formats uses DTX and VAD 
with CN so that the active speech can easily be separated from 
background noise periods. Also is not the derivation of the value 
backwards? Should it not be (double talk intervals / total number of 
intervals)*254? It seems to be better to use 254 as the division can 
produce 1.0 as a valid value and a multiplication with 256 would result 
in overflow, use of 255 would give an unavailable result.

17. Section 4.7.6 Noise level: The same problem of defining what is a 
silent period and that the signal is background noise.

18. Section 4.7.6 MOS-CQ: Missing definition of how value should be 
given. I assume similar to MOS-LQ and making value = 10*MOS.

19. Section 4.7.7: I think a more elaborate explanation on how to derive 
Gmin for different applications are needed. As many payload formats 
allow for packing of several frames in the same packet the Gmin value 
resulting in 6.25% loss without bursts is much less.

20. There are two sections 4.7.7.

21. Section 4.7.7 (The second one): The calculation of packet loss can't 
really be performed as "if (packet loss) increase packet_loss_counter". 
One usually have to calculate it backwards as (packet_loss = 
Expected_packets - arrived_packets). I also find the  proposed algorithm 
rather confusing as some steps are missing. For example the handling of 
pkt is not included. Make more complete or remove and really on textual 
description.

22. Section 5: I think you should reserve value 255 for future 
extensions. In the case that this becomes very successful and all report 
block types are used up the 255 can be defined for extensions.

23. Section 5. I think you need to use more clear terms on how to assign 
number in the registry of block types. It seems that you would like to 
have numbers assigned with the following rules: First come first served, 
registration requires a IETF standards document. Please read RFC 2434, 
for more information on what to put in there
ftp://ftp.rfc-editor.org/in-notes/rfc2434.txt

24. Section 6: I think especially the VoIP report block needs more 
wording in the security consideration. The application will expose 
information about a couple of implementation choices/configuration when 
using this format. At the same time they are required to insert if the 
format is present at all.

25. Have anybody considered any signaling to be able to indicate what 
report blocks that should be sent in this session and not. As they are 
optional it would be good if it possible for an application to inform 
the other party that it will send and would like to receive certain 
block types. Such a signaling seems to be one each media level and not 
on payload type level.

26. General consideration. I  think the whole document are lacking 
information on how to use these formats for non-frame based codecs. Also 
the dynamics in using both sample based and frame based codecs in a IP 
environment needs to be further considered. Parameters and codecs can 
change during a session and that will effect how certain values are to 
be interpreted.

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: Tue, 12 Nov 2002 03:09:31 +0100

Magnus, thank you for your thoughtful and detailed comments.

> will use RTCP PT 205 and 206, I would suggest that the XP packet type

I agree, we do not want to duplicate packet types!  Nor, I guess, should we
create gaps in the PT namespace.  As soon as the IANA assigns PT 205, I will
be sure to update the draft to reflect the next highest available number.

> field can only be 1 or larger for this packet type.

I agree.  This reasoning applies equally to the description of the SR packet
in the RTP specification.  I will revise the draft to simply summarize the
meaning of the length field and to refer to the semantics of that field in
the SR packet.  If there is to be any change in the language, it should
properly be in draft-ietf-avt-rtp-new.

> The case of no report blocks are already covered in a previous sentence.

Thank you for pointing this out.  Indeed, the statement "a block MAY be zero
bits long" is in contradiction with the following section, which requires
report blocks to have at least 32 bits.  Furthermore, there is no reason to
have a null report block.  I will eliminate this statement from the draft.

> old loss may change status to not lost if it arrives late.

This was an important omission in the draft.  Thank you for catching it.  At
the end of this mail is the language I intend to put in Section 4.1 to
correct the situation.

> for me to have a range specifiers that are inclusive in both ends.

The reason for this is to simplify calculations by eliminating the need to
add 1.  In the absence of wrap around, end_seq - begin_seq = the number of
packets reported upon.  My understanding is that 'last + 1' is a commonly
used idiom for maintaining a pointer to the end of a vector (as, for
example, in the C++ Standard Template Library).

> they should be only 16 bits and a whole 32 bit word can be saved.

This is an artifact from a time when the sequence numbers were meant to
represent extended sequence numbers.  Thank you for catching this.  I will
make the change you suggest in all parts of Section 4.

> reference to section 4.1 for the chunk definition.

I will make this change.

> 8. Section 4.3: Begin_seq and end_seq are 32 bits where 16 bits are
enough.

Agreed.

> should be increased with one millisecond to 1 to show a measurement was

This report type is meant only to report on a sequence number interval in
which there are no losses.  As you point out, the text does not make this
clear.  Rather than attribute special semantics to particular timestamp
values, my sense is that additional reports should be filed in the event of
losses.  In addition, additional reports may be filed to cover duplicates.
I will clarify this.

> 10. Section 4.4: begin_seq and end_seq are 32 bits where only 16 are
useful.

Agreed.

> in the rightmost 16 bits. Otherwise consistent parsing of report blocks

Thank you for catching this.  I am making the change.

> 12. Section 4.7.3
> 13. Section 4.7.3
> 14. Section 4.7.3
> 15. Is the mean a really good value to measure?
> 16. Section 4.7.5
> 17. Section 4.7.6
> 18. Section 4.7.6
> 19. Section 4.7.7

My co-author Alan Clark will address these.

> 20. There are two sections 4.7.7.

My error.  I will renumber.

> 21. Section 4.7.7 (The second one)

My co-author Alan Clark will address this.

> block types are used up the 255 can be defined for extensions.

My gut feeling is that the namespace is quite ample, especially as these are
256 values all fitting under a single RTCP packet type.  However, if this
feeling should prove wrong, it means that there will have been considerable
experience using this packet type before the namespace starts to fill up.
Wouldn't it be better to defer a design decision to a point in time when
much more information would be available, rather than specifying a special
mechanism now?

> ftp://ftp.rfc-editor.org/in-notes/rfc2434.txt

How's this?  "For the IANA to assign a number from this name space, a new
block type MUST be defined in a document that has been accepted as an RFC by
the IETF. Numbers are to be assigned first come first served."

> format is present at all.

I will let Alan take a stab at this first.

> block types. Such a signaling seems to be one each media level and not

I agree that it would be good to define this sort of signalling.  My sense
is that such definitions are not, however, necessary for this document.  I
am eager to discuss how such signalling might be done.

> change during a session and that will effect how certain values are to

I take this comment to apply to the VoIP section, and leave it to Alan to
reply.  If it is meant to apply to the other sections as well, please
clarify and I will do my best to address the concerns.

Now, as mentioned above, the new proposed language for the introduction to
Section 4.1:

This block type permits detailed reporting upon individual packet receipt
and
loss events.  Such reports could be used, for example, for MINC inference
[1] of
the topology of the multicast tree used for distributing a source's RTP
packets,
and of the loss rates along links within that tree.  Since a Boolean trace
of
lost and received RTP packets is potentially lengthy, this block type
permits
the trace to be compressed through run length encoding.

Threshold values used for per-sender and per-packet accounting for this
block
type MAY differ from those used to track the number of active senders and to
prepare SR and RR reports.  For example, a sender might be included in a
Loss
RLE report after receipt of only one packet, whereas two packets from that
sender might be required before the sender is considered valid for other
purposes (see the MIN_SEQUENTIAL in the RTP specification).  Or, for
example,
a Loss RLE report might treat a single large jump between sequence numbers
as
a signal that sequence numbers have advanced, whereas otherwise two packets
would have to be received before such an advance is considered to have taken
place (see the update_seq algorithm in the RTP specification).

These differences reflect the different uses to which the reports are put.
Loss
RLE reports could be used to identify unusual events.  The summary nature of
SR
and RR reports does not allow them to identify such events.

Each block reports on a single source, identified by its SSRC.  The receiver
that is supplying the report is identified in the header of the RTCP packet.

Choice of beginning and ending RTP packet sequence numbers for the trace is
left
to the application.  These values are reported in the block.  The last
sequence
number in the trace MAY differ from the sequence number reported on in any
accompanying SR or RR report.

Note that because of sequence number wrap around the ending sequence number
MAY
be less than the beginning sequence number.  A Loss RLE Block MUST NOT be
used
to report upon a range of 65,534 or greater in the sequence number space, as
there is no means to identify multiple wrap arounds.

The trace described by a Loss RLE report consists of a sequence of Boolean
values, one for each sequence number of the trace.  A value of one
represents a
packet receipt, meaning that one or more packets having that sequence number
have been received since the most recent wrap around of sequence numbers (or
since the beginning of the RTP session if no wrap around has been judged to
have
occurred).  A value of zero represents a packet loss, meaning that there has
been no packet receipt for that sequence number as of the time of the
report.
If a packet with a given sequence number is received after a report of a
loss
for that sequence number, a later Loss RLE report MAY report a packet
receipt
for that sequence number.

The encoding itself consists of a series of 16 bit chunks that describe
sequences of packet receipts or losses in the trace.  Each chunk either
specifies a run length or a bit vector, or is a null chunk.  A run length
describes between 1 and 16,383 events that are all the same (either all
receipts
or all losses).  A bit vector describes 15 events that may be mixed receipts
and
losses.  A null chunk describes no events, and is used to to round out the
block
to a 32 bit word boundary.

- Timur Friedman

---

From: "Alan Clark" <[email-masked]>
Date: Mon, 18 Nov 2002 10:59:41 -0500

Magnus

Thanks for your comments on the VoIP section of the RTCP Reporting
Extensions draft.

> We can work on the wording a little more to clarify
> In practice a value for Gmin of 16 is ideal as it results in gap
characteristics that correspond to good quality (i.e. low packet loss rate,
minimum distance of 16 received packets between lost packets) and hence
differentiates nicely between good and poor quality periods.  We can put
this value in as the recommended value.

> Agreed.  We could use the term "burst period" rather than "burst interval"

> Well caught .. the example should describe a value for Gmin of 5 or larger
however it would probably be less confusing to just state "for the default
value for Gmin of 16"

> Since the gap/ burst metrics are describing the call in terms of periods
of good and poor quality then a fair amount of information is preserved.
The problem with an IIR type approach is that it heavily weights the most
recent history.  For example with the RTCP jitter example you give, the
reported jitter value is significantly influenced only by the most recent
2-300 milliseconds and says almost nothing about the history up to that
point. In other words, RTCP RR jitter values really describe the few hundred
milliseconds prior to the report being sent and don't provide much
indication of the 5-10 second period between reports.
> With the approach described in this draft - say period of 3 seconds of
heavy congestion occurred 20 seconds into a VoIP call, this would result in
a high level of discards and hence would be identified as a burst of
(loss/discard) lasting 3 seconds; this information would be retained for the
entire call, and hence at any point up to the end of the call you could
identify that this event had occurred and also estimate a MOS or R factor if
needed (e.g. MOS during gap periods was 4.1 but MOS during burst was 2.5).

> Many vocoder implementations already include an energy detector, and I
believe that the operation of these is a little vendor specific.  The idea
behind this parameter is that the existing speech energy detector
implemented in the vocoder software is used - even if VAD is not enabled.
> With regard to the order of calculation and scaling - Agreed

> Again, the goal would be to use the existing vocoder energy detector
rather than requiring implementation of a second algorithm.

> Agreed

> In practice a value of 16 for Gmin works well for VoIP regardless of frame
packing however a larger value is needed for video applications, basically
because the threshold over which significant degradation occurs is much
lower.  Within the context of Section 4.7 I would advocate staying with the
default value.  For the frame packing example - as long as the frames/packet
remains constant then the frame loss rate and packet loss rate are the same;
the principal difference is that if a packet containing multiple frames is
lost then in theory you could never get an isolated loss.  We (and others)
have found that for 10mS frames there is not much difference between 1, 2 or
3 consecutive lost frames and it seems that within the industry people aim
for an overall packet size corresponding to 20-30mS of speech. Hence if you
apply this model at a packet level rather than a frame level then it is
quite effective.

> Agreed - the second should be 4.7.8

> Actually the sample C code "Example of burst packet loss calculation"
really belongs in either Section 4.7.9 or an Appendix to the document.
>This is an event driven algorithm and hence the first line of the algorithm
is not calculating the number of lost packets (assumed to be 1) but
identifying from a boolean variable if the event was a packet loss or a
packet discard. We can add a sentence to the end of the preceding paragraph
to say "packet_lost and packet_discarded are boolean variables that indicate
if the event that resulted in this function being invoked was a lost or
discarded packet".

>Good points.  In general the issue of sample vs frame based codecs should
not matter for the specific algorithms identified in this document (as it is
packet based) although they would have an impact on the method of
calculating estimated MOS scores and R factors.
>We should add a note to say that if configuration changes, such as codec
type, are made during a call then it is recommended that a VoIP metrics
report is sent at that time.

Regards

Alan