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

From: "Timur Friedman" <[email-masked]>
Date: Tue, 18 Feb 2003 02:31:50 -0500

Hello Joerg,

Saving a full octet in an RTP XR block header is indeed tempting.  Thank you for bringing this issue to our attention again.  I don't think it has yet gotten the scrutiny it deserves.

The following concerns lead me to hesitate about making the change:

- Although RTP XR blocks should stay small (for scalability), one can envision good reasons for the occasional large report block.

- The large report blocks are the ones that would benefit the most from compression.  If the reported data are compressible, we wish to afford them a good compression ratio.  It could be that, by requiring the data to be divided up into pieces before being compressed (in order to fit into 1020 byte units), we hurt the compression ratio.  I do not have concrete examples to cite, but to my mind this is a real possibility.

- Fragmentation and reassembly (in this case of reports, at the RTCP level) impose overhead.

- It is true that SDES elements are limited by an 8 bit length field.  However the elements, names, e-mail addresses, phone numbers, etc., are relatively short.  The note or the private element might be an exception.  In the case of RTP XR, several of the blocks are potentially very long (timestamp reports, for example).  While it is a good general policy to limit their size, in my mind it is better to limit them as a function of the application's requirements and the environment (including MTU) rather than imposing an a priori constraint that is much less than the possible size of an RTCP packet.

- The usual MTU is a constraint.  But it is also something subject to change depending upon the environment, and a value that might well evolve over the long term.  We don't necessarily want to lock in to a constraint that is subject to such change.

- None of the report blocks currently defined in the RTP XR draft could be shortened by a full 32 bit word if the length field were reduced from 16 bits to 8 bits.

One compelling argument in favor of the shortening would be a report block that would benefit.  But I would remain concerned about the issues that I have listed.

Best regards,

Timur

> -----Original Message-----
> From: Joerg Ott [mailto:[email-masked]]
> Sent: Monday, February 17, 2003 1:12 PM
> To: Timur Friedman
> Cc: [email-masked]; Ramon Caceres; Alan Clark; Kevin Almeroth; Kamil
> Sarac; Robert Cole; Kaynam Hedayat; Nick Duffield
> Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt
> 
> 
> Timur,
> 
> while we are at it: I am currently revising the SSM RTCP draft and
> hence came across an issue I also mentioned at the last IETF:
> wouldn't it make sense to slightly revise the first few bytes of the
> XR blocks defined in section 3:
> 
> (sorry if you have gone through this again and again)
> 
> From:
> 
>      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       | type-specific |         block length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     :                      type-specific data                       :
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> To:
> 
>      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       | block length  |       type-specific data      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     :                      type-specific data                       :
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> The first byte of your type-specific data field could easily become
> the "type-specific" field before.
> 
> As you are measuring block size if multiples of 32 bits, an 8 bit
> value will cover block sizes of up to 1,020 bytes which seems quite
> a lot (particularly as the packets are supposed to fit into a usual
> MTU).  If you need more, you could just include the same block
> several times.  You'll save one byte or two per report block.
> 
> BTW: Except for the alignment requirement, the above structure would
> also mirror the SDES format.
> 
> Joerg

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

---

From: Joerg Ott <[email-masked]>
Date: Mon, 17 Feb 2003 19:11:53 +0100

Timur,

From:

     0                   1                   2                   3

To:

     0                   1                   2                   3

Joerg

Timur Friedman wrote:

> Hello,
> 
> Please find attached the latest version of the (new title) RTP Extended 
> Reports (RTP XR) draft, draft-ietf-avt-rtcp-report-extns-02.txt.  This has 
> just been submitted to [email-masked]. We have updated the draft 
> based upon comments from this list and from the chairs.
> 
> We hope to advance to Final Call at the March IETF in San Francisco.  Your 
> comments are most welcome so that we may issue a final draft in good time.
> 
> Here are the changes since the previous version:
> 
> * Changed title from RTCP Reporting Extensions to RTP Extended Reports
>   (RTP XR).  (Only very well known acronyms may appear in the title
>   without expansion.  RTP appears in the titles of several RFCs, RTCP
>   in none to date.)
> 
> * Reduced author list from seven authors to three editors.  Created a
>   Contributors section.  Nick Duffield added as author.  (No more than five
>   names allowed on the front page authors list, mentioned by Colin.)
> 
> * Added Magnus Westerlund, Dorgham Sisalem, and Adam Wolisz to the
>   acknowledgments.
> 
> * Separated normative from informative references.  (Now recommended
>   by the RFC Editor, mentioned by Colin.)
> 
> * Renumbered the RTP packet type (PT) value for XR packets to 207.
>   This would be the next available value should the RTCP feedback
>   draft, which is in last call, become an RFC.  Note that this would
>   require changes to any other drafts based on the XR packet (RTCP
>   Extensions for Single-Source Multicast is one).
> 
> * Renumbered the block types from 1 to 7, replacing the legacy values.
>   (Requested by Colin in the absence of a clear rationale for the
>   legacy values.)
> 
> * Rewrote the IANA Considerations section (as recommended by Colin).
> 
> * Changed the required behavior for the receiver when it sees a
>   non-zero value in a reserved field.  Now the receiver must ignore
>   the block or packet that contains this field.  Previously the
>   receiver was to ignore the field if they were unaware of any defined
>   semantics for the field. (Allows for future definitions of these
>   fields to call for different behavior on the part of receivers.)
> 
> * All report blocks now have "Report Block" as part of their name.
>   (This was inconsistent before.)
> 
> * Some of the subsections of Section 4.7 have been combined.
> 
> * Sections at the end of the document, such as the references and the
>   copyright statement, have been reordered. References divided into
>   Normative and Non-Normative References.
> 
> * An appendix has been created for algorithms.  The formatting for
>   algorithms has been harmonized.
> 
> * The discussion of per-sender and per-packet accounting for the Loss
>   RLE Report Block (Section 4.1) has been updated, with an algorithm
>   in the appendix.
> 
> * Variable geometry removed from the Statistics Summary Report Block
>   (Section 4.4).  Now, if a statistic is not reported, the field is
>   set to zero, but the field itself is not removed.  This should
>   considerably simplify parsing.
> 
> * Clarified the wording specifying the length fields.  (Thanks to
>   Magnus Westerlund.)
> 
> * Clarified how late packets are accounted as losses.  (Thanks to
>   Henning Schulzrinne and Magnus Westerlund.)
> 
> * Made begin_seq and end_seq 16 bits in all cases.  (Thanks to Magnus
>   Westerlund.)
> 
> * Clarified what to do if there are losses or duplicates when sending
>   a Timestamp Report Block.  (Thanks to Magnus Westerlund.)
> 
> * Recommendations added to the Security Considerations section.
> 
> * Gmin recommended value of 16 indicated for VoIP Metrics Report Block
>   (Section 4.7)
> 
> * RERL calculation corrected in Section 4.7.  (Thanks to Magnus
>   Westerlund.)
> 
> * Burst metrics algorithm modified, and discussion updated.
> 
> * Field renamed in the VoIP block: doubletalk now residual echo return loss
>   (RERL). Updated discussion of this field.
> 
> * Fields reordered in VoIP block to better align on 16-bit boundaries.
> 
> * Document indenting fixed to conform to that of the RTP spec.
> 
> Regards,
> 
> Timur Friedman
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> INTERNET-DRAFT                                           24 January 2003
> Internet Engineering Task Force                    Expires: 24 July 2003
>                                                  Timur Friedman, Paris 6
>                                                  Ramon Caceres, ShieldIP
>                                                  Alan Clark, Telchemy
>                                                  Editors
>                      RTP Extended Reports (RTP XR)
> 
>                 draft-ietf-avt-rtcp-report-extns-02.txt
> 
> 
> Status of this Memo
> 
>    This document is an Internet-Draft and is subject to all provisions
>    of Section 10 of RFC2026.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/1id-abstracts.html
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
> 
> Abstract
> 
>    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
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                              [Page 1]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    (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.
> 
> Table of Contents
> 
>    1.     Introduction ..............................................  2
>    1.1    Terminology ...............................................  3
>    2.     XR Packet Format ..........................................  4
>    3.     Extended Report Block Framework ...........................  5
>    4.     Extended Report Blocks ....................................  6
>    4.1    Loss RLE Report Block .....................................  6
>    4.1.1  Run Length Chunk .......................................... 12
>    4.1.2  Bit Vector Chunk .......................................... 12
>    4.1.3  Terminating Null Chunk .................................... 12
>    4.2    Duplicate RLE Report Block ................................ 13
>    4.3    Timestamp Report Block .................................... 13
>    4.4    Statistics Summary Report Block ........................... 16
>    4.5    Receiver Timestamp Report Block ........................... 19
>    4.6    DLRR Report Block ......................................... 20
>    4.7    VoIP Metrics Report Block ................................. 21
>    4.7.1  Packet Loss and Discard Metrics ........................... 23
>    4.7.2  Burst Metrics ............................................. 23
>    4.7.3  Delay Metrics ............................................. 26
>    4.7.4  Signal Related Metrics .................................... 26
>    4.7.5  Call Quality or Transmission Quality Metrics .............. 29
>    4.7.6  Configuration Parameters .................................. 30
>    4.7.7  Jitter Buffer Parameters .................................. 31
>    5.     IANA Considerations ....................................... 32
>    5.1    XR Packet Type ............................................ 32
>    5.2    RTP XR Block Type Registry ................................ 32
>    6.     Security Considerations ................................... 33
>    A.     Algorithms ................................................ 34
>    A.1    Sequence Number Interpretation ............................ 34
>    A.2    Example Burst Packet Loss Calculation ..................... 35
>           Intellectual Property ..................................... 37
>           Full Copyright Statement .................................. 38
>           Acknowledegments .......................................... 38
>           Contributors .............................................. 39
>           Authors' Addresses ........................................ 39
>           References ................................................ 40
>           Normative References ...................................... 40
>           Non-Normative References .................................. 41
> 
> 1. Introduction
> 
>    This document defines the extended report (XR) packet type for the
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                              [Page 2]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    RTP control protocol (RTCP) [7].  XR packets convey information
>    beyond that already contained in the reception report blocks of
>    RTCP's sender report (SR) or receiver report (RR) packets.  The
>    information is of use across RTP profiles, and so is not
>    appropriately carried in SR or RR profile-specific extensions.
>    Information used for network management falls into this category, for
>    instance.
> 
>    The definition is broken out over the three following sections of
>    this document, starting with a general framework and finishing with
>    the specific information conveyed.  The framework defined by Section
>    2 contains common header information followed by a series of
>    components called report blocks.  Section 3 defines the format common
>    to such blocks.  Section 4 defines seven block types.
> 
>    Seven report block formats are defined by this document:
> 
>    - Loss RLE Report Block (Section 4.1): Run length encoding of RTP
>    packet loss reports.
> 
>    - Duplicate RLE Report Block (Section 4.2): Run length encoding of
>    reports of RTP packet duplicates.
> 
>    - Timestamp Report Block (Section 4.3): A list of timestamps of
>    received RTP packets.
> 
>    - Statistics Summary Report Block (Section 4.4): Statistics on RTP
>    packet sequence numbers, losses, duplicates, jitter, and TTL values.
> 
>    - Receiver Timestamp Report Block (Section 4.5): Receiver-end
>    timestamps that complement the sender-end timestamps already defined
>    for RTCP.
> 
>    - DLRR Report Block (Section 4.6): The delay since the last Receiver
>    Timestamp Report Block was received, allowing non-senders to
>    calculate round-trip times.
> 
>    - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring
>    Voice over IP (VoIP) calls.
> 
>    These blocks are defined within a minimal framework: a type field and
>    a length field are common to all XR blocks.  The purpose is to
>    maintain flexibility and to keep overhead low.  0ther block formats,
>    beyond the seven defined here, may be defined within this framework
>    as the need arises.
> 
> 1.1 Terminology
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                              [Page 3]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [1] and
>    indicate requirement levels for compliance with this specification.
> 
> 2. XR Packet Format
> 
>    The XR packet consists of a header of two 32-bit words, followed by a
>    number, possibly zero, of extended report blocks.
> 
> 
>     0                   1                   2                   3
>    |V=2|P|reserved |   PT=XP=207   |             length            |
>    |                           SSRC/CSRC                           |
>    :                         report blocks                         :
>    version (V): 2 bits
>         Identifies the version of RTP.  This specification applies to
>         RTP version two.
> 
>    padding (P): 1 bit
>         If the padding bit is set, this XR packet contains some
>         additional padding octets at the end.  The semantics of this
>         field are identical to the semantics of the padding field in the
>         the SR packet, as defined by the RTP specification.
> 
>    reserved: 5 bits
>         This field is reserved for future definition.  In the absence of
>         such definition, the bits in this field MUST be set to zero and
>         the receiver MUST ignore any XR packet with a non-zero value in
>         this field.
> 
>    packet type (PT): 8 bits
>         Contains the constant 207 to identify this as an RTCP XR packet.
>         This value is registered with the Internet Assigned Numbers
>         Authority (IANA), as described in Section 5.1.
> 
>    length: 16 bits
>         As described for the RTP sender report (SR) packet (see Section
>         6.3.1 of the RTP specification [7]).  Briefly, the length of
>         this XR packet in 32-bit words minus one, including the header
>         and any padding.
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                              [Page 4]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    SSRC: 32 bits
>         The synchronization source identifier for the originator of this
>         XR packet.
> 
>    report blocks: variable length.
>         Zero or more extended report blocks.  In keeping with the
>         extended report block framework defined below, each block MUST
>         consist of one or more 32-bit words.
> 
> 3. Extended Report Block Framework
> 
>    Extended report blocks are stacked, one after the other, at the end
>    of an XR packet.  An individual block's length is a multiple of 4
>    octets.  The XR header's length field describes the total length of
>    the packet, including these extended report blocks.
> 
>    Each block has block type and length fields that facilitate parsing.
>    A receiving application can demultiplex the blocks based upon their
>    type, and can use the length information to locate each successive
>    block, even in the presence of block types it does not recognize.
> 
>    An extended report block has the following format:
> 
> 
>     0                   1                   2                   3
>    block type (BT): 8 bits
>         Identifies the block format.  Seven block types are defined in
>         Section 4.  Additional block types may be defined in future
>         specifications.  This field's name space is managed by the
>         Internet Assigned Numbers Authority (IANA), as described in
>         Section 5.2.
> 
>    type-specific: 8 bits
>         The use of these bits is determined by the block type
>         definition.
> 
>    block length: 16 bits
>         The length of this report block including the header, in 32-bit
>         words minus one.  If the block type definition permits, zero is
>         an acceptable value, signifying a block that consists of only
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                              [Page 5]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>         the BT, type-specific, and block length fields, with a null
>         type-specific data field.
> 
>    type-specific data: variable length
>         The use of this field is defined by the particular block type,
>         subject to the constraint that it MUST be a multiple of 32 bits
>         long.  If the block type definition permits, It MAY be zero bits
>         long.
> 
> 4. Extended Report Blocks
> 
>    This section defines seven extended report blocks: block types for
>    losses, duplicates, packet reception timestamps, detailed reception
>    statistics, receiver timestamps, receiver inter-report delays, and
>    voice over IP (VoIP) metrics.  An implementation MAY ignore incoming
>    blocks with types either not relevant or unknown to it. Additional
>    block types MUST be registered with the Internet Assigned Numbers
>    Authority (IANA) [5], as described in Section 5.2.
> 
> 4.1 Loss RLE Report Block
> 
>    This block type permits detailed reporting upon individual packet
>    receipt and loss events.  Such reports can be used, for example, for
>    multicast inference of network characteristics (MINC) [8].  With
>    MINC, one can discover the topology of the multicast tree used for
>    distributing a source's RTP packets, and of the loss rates along
>    links within that tree.  Or they could be used to provide raw data to
>    a network management application.
> 
>    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.  To further reduce block size, loss event
>    reports can be systematically dropped from the trace in a mechanism
>    called thinning that is described below and that is studied in [9].
> 
>    A participant that generates a Loss RLE Report Block should favor
>    accuracy in reporting on observed events over interpretation of those
>    events whenever possible.  Interpretation should be left to those who
>    observe the report blocks.  Following this approach implies that
>    accounting for Loss RLE Report Blocks will differ from the accounting
>    for the generation of the SR and RR packets described in the RTP
>    specification [7] in the following two areas: per-sender accounting
>    and per-packet accounting.
> 
>    In its per-sender accounting, an RTP session participant SHOULD NOT
>    make the receipt of a threshold minimum number of RTP packets a
>    condition for reporting upon the sender of those packets.  This
>    accounting technique differs from the technique described in Section
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                              [Page 6]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    6.2.1 and Appendix A.1 of the RTP specification that allows a
>    threshold to determine whether a sender is considered valid.
> 
>    In its per-packet accounting, an RTP session participant SHOULD treat
>    all sequence numbers as valid.  This accouting technique differs from
>    the technique described in Appendix A.1 of the RTP specification that
>    suggests ruling a sequence number valid or invalid on the basis of
>    its contiguity with the sequence numbers of previously received
>    packets.
> 
>    Sender validity and sequence number validity are interpretations of
>    the raw data.  Such interpretations are justified in the interest,
>    for example, of excluding the stray old packet from an unrelated
>    session from having an effect upon the calculation of the RTCP
>    transmission interval.  The presence of stray packets might, on the
>    other hand, be of interest to a network monitoring application.
> 
>    One accounting interpretation that is still necessary is for a
>    participant to decide whether the 16 bit sequence number has rolled
>    over.  Under ordinary circumstances this is not a difficult task.
>    For example, if packet number 65,535 (the highest possible sequence
>    number) is followed shortly by packet number 0, it is reasonable to
>    assume that there has been a rollover.  However it is possible that
>    the packet is an earlier one (from 65,535 packets earlier).  It is
>    also possible that the sequence numbers have rolled over multiple
>    times, either forward or backward.  The interpretation becomes more
>    difficult when there are large gaps between the sequence numbers,
>    even accounting for rollover, and when there are long intervals
>    between received packets.
> 
>    The per-packet accounting technique mandated here is for a
>    participant to keep track of the sequence number of the packet most
>    recently received from a sender.  For the next packet that arrives
>    from that sender, the sequence number MUST be judged to fall no more
>    than 32,768 packets ahead or behind the most recent one, whichever
>    choice places it closer.  In the event that both choices are equally
>    distant (only possible when the distance is 32,768), the choice MUST
>    be the one that does not require a rollover.  Appendix A.1 presents
>    an algorithm that implements this technique.
> 
>    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.
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                              [Page 7]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    Note that because of sequence number wrap around the ending sequence
>    number MAY be less than the beginning sequence number.  A Loss RLE
>    Report 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 units called
>    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.
> 
>    The mapping from a sequence of lost and received packets into a
>    sequence of chunks is not necessarily unique.  For example, the
>    following trace covers 45 packets, of which the 22nd and 24th have
>    been lost and the others received:
> 
> 
>    1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
> 
> 
>    One way to encode this would be:
> 
> 
>    bit vector 1111 1111 1111 111
>    bit vector 1111 1101 0111 111
>    bit vector 1111 1111 1111 111
>    null chunk
> 
> 
>    Another way to encode this would be:
> 
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                              [Page 8]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    run of 21 receipts
>    bit vector 0101 1111 1111 111
>    run of 9 receipts
>    null chunk
> 
> 
>    The choice of encoding is left to the application.  As part of this
>    freedom of choice, applications MAY terminate a series of run length
>    and bit vector chunks with a bit vector chunk that runs beyond the
>    sequence number space described by the report block.  For example, if
>    the 44th packet in the same sequence were lost:
> 
> 
>    1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
> 
> 
>    This could be encoded as:
> 
> 
>    run of 21 receipts
>    bit vector 0101 1111 1111 111
>    bit vector 1111 1110 1000 000
>    null chunk
> 
> 
>    In this example, the last five bits of the second bit vector describe
>    a part of the sequence number space that extends beyond the last
>    sequence number in the trace.  These bits have been set to zero.
> 
>    All bits in a bit vector chunk that describe a part of the sequence
>    number space that extends beyond the last sequence number in the
>    trace MUST be set to zero, and MUST be ignored by the receiver.
> 
>    A null packet MUST appear at the end of a Loss RLE Report Block if
>    the number of run length plus bit vector chunks is odd.  The null
>    chunk MUST NOT appear in any other context.
> 
>    Caution should be used in sending Loss RLE Report Blocks because,
>    even with the compression provided by run length encoding, they can
>    easily consume bandwidth out of proportion with normal RTCP packets.
>    The block type includes a mechanism, called thinning, that allows an
>    application to limit report sizes.
> 
>    A thinning value, T, selects a subset of packets within the sequence
>    number space: those with sequence numbers that are multiples of 2^T.
>    Packet reception and loss reports apply only to those packets.  T can
>    vary between 0 and 15.  If T is zero then every packet in the
>    sequence number space is reported upon.  If T is fifteen then one in
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                              [Page 9]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    every 32,768 packets is reported upon.
> 
>    Suppose that the trace just described begins at sequence number
>    13,821.  The last sequence number in the trace is 13,865.  If the
>    trace were to be thinned with a thinning value of T=2, then the
>    following sequence numbers would be reported upon: 13,824, 13,828,
>    13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860,
>    13,864.  The thinned trace would be as follows:
> 
> 
>       1    1    1    1    1    0    1    1    1    1    0
> 
> 
>    This could be encoded as follows:
> 
> 
>    bit vector 1111 1011 1100 000
>    null chunk
> 
> 
>    The last four bits in the bit vector, representing sequence numbers
>    13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are
>    thus set to zero and are ignored by the receiver.  With thinning, the
>    loss of the 22nd packet goes unreported because its sequence number,
>    13,842, is not a multiple of four.  Packet receipts for all sequence
>    numbers that are not multiples of four also go unreported.  However,
>    in this example thinning has permitted the Loss RLE Report Block to
>    be shortened by one 32 bit word.
> 
>    Choice of the thinning value is left to the application.
> 
>    The Loss RLE Report Block has the following format:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 10]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>     0                   1                   2                   3
>    |     BT=1      | rsvd. |   T   |         block length          |
>    |                        SSRC of source                         |
>    |          begin_seq            |             end_seq           |
>    |          chunk 1              |             chunk 2           |
>    :                              ...                              :
>    |          chunk n-1            |             chunk n           |
>    block type (BT): 8 bits
>         A Loss RLE Report Block is identified by the constant 1.
> 
>    rsvd.: 4 bits
>         This field is reserved for future definition.  In the absence of
>         such definition, the bits in this field MUST be set to zero and
>         the receiver MUST ignore any Loss RLE Report Block with a non-
>         zero value in this field.
> 
>    thinning (T): 4 bits
>         The amount of thinning performed on the sequence number space.
>         Only those packets with sequence numbers 0 mod 2^T are reported
>         on by this block.  A value of 0 indicates that there is no
>         thinning, and all packets are reported on.  The maximum thinning
>         is one packet in every 32,768 (amounting to two packets within
>         each 16-bit sequence space).
> 
>    block length: 16 bits
>         Defined in Section 3.
> 
>    begin_seq: 16 bits
>         The first sequence number that this block reports on.
> 
>    end_seq: 16 bits
>         The last sequence number that this block reports on plus one.
> 
>    chunk i: 16 bits
>         There are three chunk types: run length, bit vector, and
>         terminating null, defined in the following sections.  If the
>         chunk is all zeroes then it is a terminating null chunk.
>         Otherwise, the leftmost bit of the chunk determines its type: 0
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 11]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>         for run length and 1 for bit vector.
> 
> 4.1.1 Run Length Chunk
> 
> 
>     0                   1
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |C|R|        run length         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>    chunk type (C): 1 bit
>         A zero identifies this as a run length chunk.
> 
>    run type (R): 1 bit
>         Zero indicates a run of 0s.  One indicates a run of 1s.
> 
>    run length: 14 bits
>         A value between 1 and 16,383.  The value MUST not be zero for a
>         run length chunk (zeroes in both the run type and run length
>         fields would make the chunk a terminating null chunk).  Run
>         lengths of 15 or less MAY be described with a run length chunk
>         despite the fact that they could also be described as part of a
>         bit vector chunk.
> 
> 4.1.2 Bit Vector Chunk
> 
> 
>     0                   1
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |C|        bit vector           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>    chunk type (C): 1 bit
>         A one identifies this as a bit vector chunk.
> 
>    bit vector: 15 bits
>         The vector is read from left to right, in order of increasing
>         sequence number (with the appropriate allowance for wrap
>         around).
> 
> 4.1.3 Terminating Null Chunk
> 
>    This chunk is all zeroes.
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 12]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>     0                   1
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 4.2 Duplicate RLE Report Block
> 
>    This block type permits per-sequence-number reports on duplicates in
>    a source's RTP packet stream.  Such information can be used for
>    network diagnosis, and provide an alternative to packet losses as a
>    basis for multicast tree topology inference.
> 
>    The Duplicate RLE Report Block format is identical to the Loss RLE
>    Report Block format.  Only the interpretation is different, in that
>    the information concerns packet duplicates rather than packet losses.
>    The trace to be encoded in this case also consists of zeros and ones,
>    but a zero here indicates the presence of duplicate packets for a
>    given sequence number, whereas a one indicates that no duplicates
>    were received.
> 
>    The existence of a duplicate for a given sequence number is
>    determined over the entire reporting period.  For example, if packet
>    number 12,593 arrives, followed by other packets with other sequence
>    numbers, the arrival later in the reporting period of another packet
>    numbered 12,593 counts as a duplicate for that sequence number.  The
>    duplicate does not need to follow immediately upon the first packet
>    of that number.  Care must be taken that a report does not cover a
>    range of 65,534 or greater in the sequence number space.
> 
>    No distinction is made between the existance of a single duplicate
>    packet and multiple duplicate packets for a given sequence number.
>    Note also that since there is no duplicate for a lost packet, a loss
>    is encoded as a one in a Duplicate RLE Report Block.
> 
>    The Duplicate RLE Report Block has the following format:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 13]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>     0                   1                   2                   3
>    |     BT=2      | rsvd. |   T   |         block length          |
>    |                        SSRC of source                         |
>    |          begin_seq            |             end_seq           |
>    |          chunk 1              |             chunk 2           |
>    :                              ...                              :
>    |          chunk n-1            |             chunk n           |
>    block type (BT): 8 bits
>         A Duplicate RLE Report Block is identified by the constant 2.
> 
>    rsvd.: 4 bits
>         This field is reserved for future definition.  In the absence of
>         such definition, the bits in this field MUST be set to zero and
>         the receiver MUST ignore any Duplicate RLE Report Block with a
>         non-zero value in this field.
> 
>    thinning (T): 4 bits
>         As defined in Section 4.1.
> 
>    block length: 16 bits
>         Defined in Section 3.
> 
>    begin_seq: 16 bits
>         As defined in Section 4.1.
> 
>    end_seq: 16 bits
>         As defined in Section 4.1.
> 
>    chunk i: 16 bits
>         As defined in Section 4.1.
> 
> 4.3 Timestamp Report Block
> 
>    This block type permits per-sequence-number reports on packet receipt
>    timestamps for a given source's RTP packet stream.  Such information
>    can be used for MINC inference of the topology of the multicast tree
>    used to distribute the source's RTP packets, and of the delays along
>    the links within that tree.  It can also be used to measure partial
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 14]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    path characteristics and to model distributions for packet jitter.
> 
>    At least one packet MUST have been received for each sequence number
>    reported upon in this block.  If this block type is used to report
>    timestamps for a series of sequence numbers that includes lost
>    packets, several blocks are required.  If duplicate packets have been
>    received for a given sequence number, and those packets differ in
>    their receiver timestamps, any timestamp other than the earliest MUST
>    NOT be reported.  This is to ensure consistency among reports.
> 
>    Timestamps consume more bits than loss or duplicate information, and
>    do not lend themselves to run length encoding.  The use of thinning
>    is encouraged to limit the size of Timestamp Report Blocks.
> 
>    The Timestamp Report Block has the following format:
> 
> 
>     0                   1                   2                   3
>    |     BT=3      | rsvd. |   T   |         block length          |
>    |                        SSRC of source                         |
>    |          begin_seq            |             end_seq           |
>    |                        RTP timestamp 1                        |
>    |                        RTP timestamp 2                        |
>    :                              ...                              :
>    |                        RTP timestamp n                        |
>    block type (BT): 8 bits
>         A Timestamp Report Block is identified by the constant 3.
> 
>    rsvd.: 4 bits
>         This field is reserved for future definition.  In the absence of
>         such definition, the bits in this field MUST be set to zero and
>         the receiver MUST ignore any Timestamp Report Block with a non-
>         zero value in this field.
> 
>    thinning (T): 4 bits
>         As defined in Section 4.1.
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 15]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    block length: 16 bits
>         Defined in Section 3.
> 
>    begin_seq: 16 bits
>         As defined in Section 4.1.
> 
>    end_seq: 16 bits
>         As defined in Section 4.1.
> 
>    RTP timestamp i: 32 bits
>         The timestamp reflects the packet arrival time at the receiver.
>         It is preferable for the timestamp to be established at the link
>         layer interface, or in any case as close as possible to the wire
>         arrival time.  Units and format are the same as for the
>         timestamp in RTP data packets.  As opposed to RTP data packet
>         timestamps, in which nominal values may be used instead of
>         system clock values in order to convey information useful for
>         periodic playout, the receiver timestamps should reflect the
>         actual time as closely as possible.  The initial value of the
>         timestamp is random, and subsequent timestamps are offset from
>         this value.
> 
> 4.4 Statistics Summary Report Block
> 
>    This block reports statistics beyond the information carried in the
>    standard RTCP packet format, but not as fine grained as that carried
>    in the report blocks previously described.  Information is recorded
>    about lost packets, duplicate packets, jitter measurements, and TTL
>    values (TTL values being taken from the TTL field of IPv4 packets, if
>    the data packets are carried over IPv4).  Such information can be
>    useful for network management.
> 
>    The report block contents are dependent upon a bit vector carried in
>    the first part of the header.  Not all parameters need to be reported
>    in each block.  Flags indicate which are and which are not reported.
>    The fields corresponding to unreported parameters MUST be set to
>    zero. The receiver MUST ignore any Statistics Summary Report Block
>    with a non-zero value in any field flagged as unreported.
> 
>    The Statistics Summary Report Block has the following format:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 16]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>     0                   1                   2                   3
>    |     BT=4      |L|D|J|T|resvd. |       block length = 9        |
>    |                        SSRC of source                         |
>    |          begin_seq            |             end_seq           |
>    |                        lost_packets                           |
>    |                        dup_packets                            |
>    |                         min_jitter                            |
>    |                         max_jitter                            |
>    |                         avg_jitter                            |
>    |                         dev_jitter                            |
>    |   min_ttl     |   max_ttl     |   avg_ttl     |     dev_ttl   |
>    block type (BT): 8 bits
>         A Statistics Summary Report Block is identified by the constant
>         4.
> 
>    loss report flag (L): 1 bit
>         Bit set to 1 if the lost_packets field contains a report, 0
>         otherwise.
> 
>    duplicate report flag (D): 1 bit
>         Bit set to 1 if the dup_packets field contains a report, 0
>         otherwise.
> 
>    jitter flag (J): 1 bit
>         Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and
>         dev_jitter fields all contain reports, 0 if none of them do.
> 
>    TTL flag (T): 1 bit
>         Bit set to 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl
>         fields all contain reports, 0 if none of them do.
> 
>    resvd.: 4 bits
>         This field is reserved for future definition.  In the absence of
>         such definition, all bits in this field MUST be set to zero, and
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 17]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>         the receiver MUST ignore any Statistics Summary Report Block
>         with a non-zero value in this field.
> 
>    block length: 16 bits
>         The constant 9, in accordance with the definition of this field
>         in Section 3.
> 
>    begin_seq: 16 bits
>         As defined in Section 4.1.
> 
>    end_seq: 16 bits
>         As defined in Section 4.1.
> 
>    lost_packets: 32 bits
>         Number of lost packets in the above sequence number interval.
> 
>    dup_packets: 32 bits
>         Number of duplicate packets in the above sequence number
>         interval.
> 
>    min_jitter: 32 bits
>         The minimum relative transit time between two packets in the
>         above sequence number interval.  All jitter values are measured
>         as the difference between a packet's RTP timestamp and the
>         reporter's clock at the time of arrival, measured in the same
>         units.
> 
>    max_jitter: 32 bits
>         The maximum relative transit time between two packets in the
>         above sequence number interval.
> 
>    avg_jitter: 32 bits
>         The average relative transit time between each two packet series
>         in the above sequence number interval.
> 
>    dev_jitter: 32 bits
>         The standard deviation of the relative transit time between each
>         two packet series in the above sequence number interval.
> 
>    min_ttl: 8 bits
>         The minimum TTL value of data packets in sequence number range.
> 
>    max_ttl: 8 bits
>         The maximum TTL value of data packets in sequence number range.
> 
>    avg_ttl: 8 bits
>         The average TTL value of data packets in sequence number range.
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 18]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    dev_ttl: 8 bits
>         The standard deviation of TTL values of data packets in sequence
>         number range.
> 
> 4.5 Receiver Timestamp Report Block
> 
>    This block extends RTCP's timestamp reporting so that non-senders may
>    also send timestamps.  It recapitulates the NTP timestamp fields from
>    the RTCP Sender Report [7, Sec. 6.3.1].  A non-sender may estimate
>    its RTT to other participants, as proposed in [11], by sending this
>    report block and receiving DLRR Report Blocks (see next section) in
>    reply.
> 
> 
>     0                   1                   2                   3
>    |     BT=5      |   reserved    |       block length = 2        |
>    |              NTP timestamp, most significant word             |
>    |             NTP timestamp, least significant word             |
>    block type (BT): 8 bits
>         A Receiver Timestamp Report Block is identified by the constant
>         5.
> 
>    reserved: 8 bits
>         This field is reserved for future definition.  In the absence of
>         such definition, the bits in this field MUST be set to zero and
>         the receiver MUST ignore any Receiver Timestamp Report Block
>         with a non-zero value in this field.
> 
>    block length: 16 bits
>         The constant 2, in accordance with the definition of this field
>         in Section 3.
> 
>    NTP timestamp: 64 bits
>         Indicates the wallclock time when this block was sent so that it
>         may be used in combination with timestamps returned in DLRR
>         Report Blocks (see next section) from other receivers to measure
>         round-trip propagation to those receivers.  Receivers should
>         expect that the measurement accuracy of the timestamp may be
>         limited to far less than the resolution of the NTP timestamp.
>         The measurement uncertainty of the timestamp is not indicated as
>         it may not be known. A report block sender that can keep track
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 19]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>         of elapsed time but has no notion of wallclock time may use the
>         elapsed time since joining the session instead. This is assumed
>         to be less than 68 years, so the high bit will be zero.  It is
>         permissible to use the sampling clock to estimate elapsed
>         wallclock time. A report sender that has no notion of wallclock
>         or elapsed time may set the NTP timestamp to zero.
> 
> 4.6 DLRR Report Block
> 
>    This block extends RTCP's delay since last sender report (DLSR)
>    mechanism [7, Sec. 6.3.1] so that non-senders may also calculate
>    round trip times, as proposed in [11].  It is termed DLRR for delay
>    since last receiver report, and may be sent in response to a Receiver
>    Timestamp Report Block (see previous section) from a receiver to
>    allow that receiver to calculate its round trip time to the
>    respondant.  The report consists of one or more 3 word sub-blocks:
>    one sub-block per receiver report.
> 
> 
>     0                   1                   2                   3
>    |     BT=6      |   reserved    |         block length          |
>    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>    |                 SSRC_1 (SSRC of first receiver)               | sub-
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
>    |                         last RR (LRR)                         |   1
>    |                   delay since last RR (DLRR)                  |
>    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>    |                 SSRC_2 (SSRC of second receiver)              | sub-
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
>    :                               ...                             :   2
>    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> 
> 
>    block type (BT): 8 bits
>         A DLRR Report Block is identified by the constant 6.
> 
>    reserved: 8 bits
>         This field is reserved for future definition.  In the absence of
>         such definition, all bits in this field MUST be set to zero, the
>         receiver MUST ignore any DLRR Report Block with a non-zero value
>         in this field.
> 
>    block length: 16 bits
>         Defined in Section 3.
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 20]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    last RR timestamp (LRR): 32 bits
>         The middle 32 bits out of 64 in the NTP timestamp (as explained
>         in the previous section) received as part of a Receiver
>         Timestamp Report Block from participant SSRC_n. If no such block
>         has been received, the field is set to zero.
> 
>    delay since last RR (DLRR): 32 bits
>         The delay, expressed in units of 1/65536 seconds, between
>         receiving the last Receiver Timestamp Report Block from
>         participant SSRC_n and sending this DLRR Report Block.  If no
>         Receiver Timestamp Report Block has been received yet from
>         SSRC_n, the DLRR field is set to zero (or the DLRR is omitted
>         entirely). Let SSRC_r denote the receiver issuing this DLRR
>         Report Block. Participant SSRC_n can compute the round-trip
>         propagation delay to SSRC_r by recording the time A when this
>         Receiver Timestamp Report Block is received.  It calculates the
>         total round-trip time A-LSR using the last SR timestamp (LSR)
>         field, and then subtracting this field to leave the round-trip
>         propagation delay as A-LSR-DLSR. This is illustrated in [7, Fig.
>         2].
> 
> 4.7 VoIP Metrics Report Block
> 
>    The VoIP Metrics Report Block provides metrics for monitoring voice
>    over IP (VoIP) calls.  These metrics include packet loss and discard
>    metrics, delay metrics, analog metrics, and voice quality metrics.
>    The block reports separately on packets lost on the IP channel, and
>    those that have been received but then discarded by the receiving
>    jitter buffer.  It also reports on the combined effect of losses and
>    discards, as both have equal effect on call quality.
> 
>    In order to properly assess the quality of a Voice over IP call it is
>    desirable to consider the degree of burstiness of packet loss [10].
>    Following a Gilbert-Elliott model [2], a period of time, bounded by
>    lost and/or discarded packets, with a high rate of losses and/or
>    discards is a "burst," and a period of time between two bursts is a
>    "gap."  Bursts correspond to periods of time during which the packet
>    loss rate is high enough to produce noticeable degradation in audio
>    quality.  Gaps correspond to periods of time during which only
>    isolated lost packets may occur, and in general these can be masked
>    by packet loss concealment.  Delay reports include the transit delay
>    between RTCP end points and the VoIP end system processing delays,
>    both of which contribute to the user perceived delay.  Additional
>    metrics include signal, echo, noise, and distortion levels.  Call
>    quality metrics include R factors (as described by the E Model
>    defined in [2]) and mean opinion scores (MOS scores).
> 
>    An implementation that sends these blocks SHOULD send at least one
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 21]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    every ten seconds for the duration of the call, SHOULD send one
>    whenever a CODEC type change or other significant change occurs,
>    SHOULD send one when significant call quality degradation is detected
>    and SHOULD send one upon call termination.  Implementations MUST
>    provide values for all the fields defined here.  For certain metrics,
>    if the value is undefined or unknown, then the specified default or
>    unknown field value MUST be provided.
> 
>    The block is encoded as seven 32-bit words:
> 
> 
>     0                   1                   2                   3
>    |     BT=7      |   reserved    |       block length = 6        |
>    |   loss rate   | discard rate  | burst density |  gap density  |
>    |       burst duration          |         gap duration          |
>    |     round trip delay          |       end system delay        |
>    | signal power  |     RERL      |  noise level  |     Gmin      |
>    |   R factor    | ext. R factor |    MOS-LQ     |    MOS-CQ     |
>    |   RX config   |  JB nominal   |  JB maximum   |  JB abs max   |
>    block type (BT): 8 bits
>         A VoIP Metrics Report Block is identified by the constant 7.
> 
>    reserved: 8 bits
>         This field is reserved for future definition.  In the absence of
>         such definition, all bits in this field MUST be set to zero and
>         the receiver MUST ignore any VoIP Metrics Report Block with a
>         non-zero value in this field.
> 
>    block length: 16 bits
>         The constant 6, in accordance with the definition of this field
>         in Section 3.
> 
>    The remaining fields are described in the following six sections:
>    Packet Loss and Discard Metrics, Delay Metrics, Signal Related
>    Metrics, Call Quality or Transmission Quality Metrics, Configuration
>    Metrics, and Jitter Buffer Parameters.
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 22]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
> 4.7.1 Packet Loss and Discard Metrics
> 
>    It is very useful to distinguish between packets lost by the network
>    and those discarded due to jitter. Both have equal effect on the
>    quality of the voice stream however having separate counts helps
>    identify the source of quality degradation. These fields MUST be
>    populated.
> 
>    loss rate: 8 bits
>         The fraction of RTP data packets from the source lost since the
>         beginning of reception, expressed as a fixed point number with
>         the binary point at the left edge of the field.  This value is
>         calculated by dividing the total number of packets lost (after
>         the effects of applying any error protection such as FEC) by the
>         total number of packets expected, multiplying the result of the
>         division by 256, limiting the maximum value to 255 (to avoid
>         overflow), and taking the integer part.  The numbers of
>         duplicated packets and discarded packets do not enter into this
>         calculation.  Since receivers cannot be required to maintain
>         unlimited buffers, a receiver MAY categorize late-arriving
>         packets as lost.  The degree of lateness that triggers a loss
>         SHOULD be significantly greater than that which triggers a
>         discard.
> 
>    discard rate: 8 bits
>         The fraction of RTP data packets from the source that have been
>         discarded since the beginning of reception, due to late or early
>         arrival, under-run or overflow at the receiving jitter buffer.
>         This value is expressed as a fixed point number with the binary
>         point at the left edge of the field.  It is calculated by
>         dividing the total number of packets discarded (excluding
>         duplicate packet discards) by the total number of packets
>         expected, multiplying the result of the division by 256,
>         limiting the maximum value to 255 (to avoid overflow), and
>         taking the integer part.
> 
> 4.7.2 Burst Metrics
> 
>    A burst, informally, is a period of high packet losses and/or
>    discards.  Formally, a burst is defined as a longest sequence of
>    packets bounded by lost or discarded packets with the constraint that
>    within a burst any sequence of successive packets that were received,
>    and not discarded due to delay variation, is of length less than a
>    value Gmin.
> 
>    A gap, informally, is a period of low packet losses and/or discards.
>    Formally, a gap is defined as any of the following: (a) the period
>    from the start of an RTP session to the receipt time of the last
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 23]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    received packet before the first burst, (b) the period from the end
>    of the last burst to either the time of the report or the end of the
>    RTP session, whichever comes first, or (c) the period of time between
>    two bursts.
> 
>    For the purpose of determining if a lost or discarded packet near the
>    start or end of an RTP session is within a gap or a burst it is
>    assumed that the RTP session is preceded and followed by at least
>    Gmin received packets, and that the time of the report is followed by
>    at least Gmin received packets.
> 
>    A gap has the property that any lost or discarded packets within the
>    gap must be preceded and followed by at least Gmin packets that were
>    received and not discarded.  This gives a maximum loss/discard
>    density within a gap of: 1 / (Gmin + 1).
> 
>    A Gmin value of 16 is RECOMMENDED as it results in gap
>    characteristics that correspond to good quality (i.e. low packet loss
>    rate, a minimum distance of 16 received packets between lost packets)
>    and hence differentiates nicely between good and poor quality
>    periods.
> 
>    For example, a 1 denotes a received, 0 a lost, and X a discarded
>    packet in the following pattern covering 64 packets:
> 
> 
>    11110111111111111111111X111X1011110111111111111111111X111111111
>    |---------gap----------|--burst---|------------gap------------|
> 
> 
>    The burst consists of the twelve packets indicated above, starting at
>    a discarded packet and ending at a lost packet.  The first gap starts
>    at the beginning of the session and the second gap ends at the time
>    of the report.
> 
>    If the packet spacing is 10 ms and the Gmin value is the recommended
>    value of 16, the burst duration is 120 ms, the burst density 0.33,
>    the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.
> 
>    This would result in reported values as follows (see field
>    descriptions for semantics and details on how these are calculated):
> 
>    loss density          12, which corresponds to 5%
>    discard density       12, which corresponds to 5%
>    burst density         84, which corresponds to 33%
>    gap density           10, which corresponds to 4%
>    burst duration       120, value in milliseconds
>    gap duration         520, value in milliseconds
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 24]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    burst density: 8 bits
>         The fraction of RTP data packets within burst periods since the
>         beginning of reception that were either lost or discarded.  This
>         value is expressed as a fixed point number with the binary point
>         at the left edge of the field.  It is calculated by dividing the
>         total number of packets lost or discarded (excluding duplicate
>         packet discards) within burst periods by the total number of
>         packets expected within the burst periods, multiplying the
>         result of the division by 256, limiting the maximum value to 255
>         (to avoid overflow), and taking the integer part.
> 
>    gap density: 8 bits
>         The fraction of RTP data packets within inter-burst gaps since
>         the beginning of reception that were either lost or discarded.
>         The value is expressed as a fixed point number with the binary
>         point at the left edge of the field.  It is calculated by
>         dividing the total number of packets lost or discarded
>         (excluding duplicate packet discards) within gap periods by the
>         total number of packets expected within the gap periods,
>         multiplying the result of the division by 256, limiting the
>         maximum value to 255 (to avoid overflow), and taking the integer
>         part.
> 
>    burst duration: 16 bits
>         The mean duration, expressed in milliseconds, of the burst
>         periods that have occurred since the beginning of reception.
>         The duration of each period is calculated based upon the packets
>         that mark the beginning and end of that period.  It is equal to
>         the timestamp of the end packet, plus the duration of the end
>         packet, minus the timestamp of the beginning packet.  If the
>         actual values are not available, estimated values MUST be used.
>         If there have been no burst periods, the burst duration value
>         MUST be zero.
> 
>    gap duration: 16 bits
>         The mean duration, expressed in milliseconds, of the gap periods
>         that have occurred since the beginning of reception.  The
>         duration of each period is calculated based upon the packet that
>         marks the end of the prior burst and the packet that marks the
>         beginning of the subsequent burst. It is equal to the timestamp
>         of the subsequent burst packet, minus the timestamp of the prior
>         burst packet, plus the duration of the prior burst packet.  If
>         the actual values are not available, estimated values MUST be
>         used.  In the case of a gap that occurs at the beginning of
>         reception, the sum of the timestamp of the prior burst packet
>         and the duration of the prior burst packet are replaced by the
>         reception start time.  In the case of a gap that occurs at the
>         end of reception, the timestamp of the subsequent burst packet
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 25]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>         is replaced by the reception end time.  If there have been no
>         gap periods, the gap duration value MUST be zero.
> 
> 4.7.3 Delay Metrics
> 
>    For the purpose of the following definitions, the RTP interface is
>    the interface between the RTP instance and the voice application
>    (i.e.  FEC, de-interleaving, de-multiplexing, jitter buffer). For
>    example, the time delay due to RTP payload multiplexing would be
>    considered to be part of the voice application or end-system delay
>    whereas delay due to multiplexing RTP frames within a UDP frame would
>    be considered part of the RTP reported delay.  This distinction is
>    consistent with the use of RTCP for delay measurements.
> 
>    round trip delay: 16 bits
>         The most recently calculated round trip time between RTP
>         interfaces, expressed in milliseconds. This value is the time of
>         receipt of the most recent RTCP packet from source SSRC, minus
>         the LSR (last SR) time reported in its SR (sender report), minus
>         the DLSR (delay since last SR) reported in its SR.  A non-zero
>         LSR value is REQUIRED in order to calculate round trip delay. A
>         value of 0 is permissible during the first two or three RTCP
>         exchanges as insufficient data may be available to determine
>         delay however MUST be populated as soon as a delay estimate is
>         available.
> 
>    end system delay: 16 bits
>         The most recently estimated end system delay, expressed in
>         milliseconds.  End system delay is defined as the total
>         encoding, decoding and jitter buffer delay determined at the
>         reporting endpoint.  This is the time required for an RTP frame
>         to be buffered, decoded, converted to analog form, looped back
>         at the local analog interface, encoded, and made available for
>         transmission as an RTP frame.  The manner in which this value is
>         estimated is implementation dependent.  This parameter MUST be
>         provided in all VoIP metrics reports.
> 
>    Note that the one way symmetric VoIP segment delay may be calculated
>    from the round trip and end system delays as follows.  If the round
>    trip delay is denoted RTD and the end system delays associated with
>    the two endpoints are ESD(A) and ESD(B) then:
> 
> 
>    one way symmetric voice path delay  =  ( RTD + ESD(A) + ESD(B) ) / 2
> 
> 
> 4.7.4 Signal Related Metrics
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 26]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    The following metrics are intended to provide real time information
>    related to the non-packet elements of the voice over IP system to
>    assist with the identification of problems affecting call quality.
>    The values identified below must be determined for the received audio
>    signal. The information required to populate these fields may not be
>    available in all systems, although it is strongly recommended that
>    this data SHOULD be provided to support problem diagnosis.
> 
>    signal power: 8 bits
>         The voice signal relative level is defined as the ratio of the
>         signal level to overflow signal level, expressed in decibels as
>         a signed integer in two's complement form.  This is measured
>         only for packets containing speech energy.  The intent of this
>         metric is not to provide a precise measurement of the signal
>         level but to provide a real time indication that the signal
>         level may be excessively high or low.  If the full range
>         (overflow level) of the Vocoder's digital to analog conversion
>         function is +/- L and the value of a decoded sample during a
>         talkspurt is V then the signal level is given by:
> 
>         signal level = 10 log10 ( mean( abs(V) / L ) )
> 
>         A value of 127 indicates that this parameter is unavailable.
> 
>    residual echo return loss (RERL): 8 bits
>         The residual echo return loss is defined as the sum of the
>         measured echo return loss (ERL) and the echo return loss
>         enhancement (ERLE) expressed in dB as a signed integer in two's
>         complement form.  It defines the ratio of a transmitted voice
>         signal that is reflected back to the talker.  A low level of
>         echo return loss (say less than 20 dB) in conjunction with some
>         delay can lead to hollowness or audible echo.  A high level of
>         echo return loss (say over 40 dB) is preferable.
> 
>    The ERL and ERLE parameters are often available directly from the
>    echo cancellor contained within the VoIP end system. They relate to
>    the echo on the external network attached to the end point.
> 
>    In the case of a VoIP gateway this would be line echo that typically
>    occurs at 2-4 wire conversion points in the network.  Echo return
>    loss from typical 2-4 wire conversions can be in the 8-12 dB range.
>    A line echo cancellor can provide an ERLE of 30 dB or more and hence
>    reduce this to 40-50 dB.  In the case of an IP phone this could be
>    residual acoustic echo from speakerphone operation, and may more
>    correctly be termed terminal coupling loss (TCL).  A typical handset
>    would result in 40-50 dB of echo due to acoustic feedback.
> 
>    Typical values for RERL are as follows:
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 27]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    (i) IP gateway connected to circuit switched network with 2 wire loop
>    Without echo cancellation, typical 2-4 wire convertor ERL of 12 dB
>    RERL = ERL + ERLE = 12 + 0 = 12 dB
> 
>    (ii) IP gateway connected to circuit switched network with 2 wire loop
>    With echo cancellor that improves echo by 30 dB
>    RERL = ERL + ERLE = 12 + 30 = 42 dB
> 
>    (iii) IP phone with conventional handset
>    Acoustic coupling from handset speaker to microphone 40 dB
>    Residual echo return loss = TCL = 40 dB
> 
>    If we denote the "local" end of the VoIP path as A and the remote end
>    as B and if the sender loudness rating (SLR) and receiver loudness
>    rating (RLR) are known for A (default values 8 dB and 2 dB
>    respectively), then the echo loudness level at end A (talker echo
>    loudness rating or TELR) is given by:
> 
>    TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
> 
>    TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)
> 
>    Hence in order to incorporate echo into a voice quality estimate at
>    the A end of a VoIP connection it is desirable to send the ERL + ERLE
>    value from B to A.
> 
>    For an IP phone with handset this metric MUST be set to the designed
>    or measured terminal coupling loss, which would typically be 40-50
>    dB.
> 
>    For a PC softphone or speakerphone this metric MUST be set to either
>    the value reported by the acoustic echo cancellor or to 127 to
>    indicate an undefined value.
> 
>    For an IP gateway with ERL and ERLE measurements this metric MUST be
>    reported as ERL + ERLE.
> 
>    For an IP gateway without ERL and ERLE measurement capability then
>    this metric MUST be reported as 12 dB if line echo cancellation is
>    disabled and 40 dB if line echo cancellation is enabled.
> 
>    noise level: 8 bits
>         The noise level is defined as the ratio of the silent period
>         back ground noise level to overflow signal power, expressed in
>         decibels as a signed integer in two's complement form.  If the
>         full range (overflow level) of the Vocoder's digital to analog
>         conversion function is +/- L and the value of a decoded sample
>         during a silence period is V then the noise level is given by
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 28]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>         noise level = 10 log10 ( mean( abs(V) / L ) )
> 
>         A value of 127 indicates that this parameter is unavailable.
> 
>    Gmin
>         See Configuration Parameters (Section 4.7.6, below).
> 
> 4.7.5 Call Quality or Transmission Quality Metrics
> 
>    The following metrics are direct measures of the call quality or
>    transmission quality, and incorporate the effects of CODEC type,
>    packet loss, discard, burstiness, delay etc.  These metrics may not
>    be available in all systems however SHOULD be provided in order to
>    support problem diagnosis.
> 
>    R factor: 8 bits
>         The R factor is a voice quality metric describing the segment of
>         the call that is carried over this RTP session.  It is expressed
>         as an integer in the range 0 to 100, with a value of 94
>         corresponding to "toll quality" and values of 50 or less
>         regarded as unusable.  This metric is defined as including the
>         effects of delay, consistent with ITU-T G.107 [4] and ETSI TS
>         101 329-5 [2].
> 
>         A value of 127 indicates that this parameter is unavailable.
> 
>    ext. R factor: 8 bits
>         The external R factor is a voice quality metric describing the
>         seg ment of the call that is carried over a network segment
>         external to the RTP segment, for example a cellular network. Its
>         values are interpreted in the same manner as for the RTP R
>         factor.  This metric is defined as including the effects of
>         delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5
>         [2], and relates to the outward voice path from the Voice over
>         IP termination for which this metrics block applies.
> 
>         A value of 127 indicates that this parameter is unavailable.
> 
>    Note that an overall R factor may be estimated from the RTP segment R
>    factor and the external R factor, as follows:
> 
>    R total = RTP R factor + ext. R factor - 94
> 
>    MOS-LQ: 8 bits
>         The estimated mean opinion score for listening quality (MOS-LQ)
>         is a voice quality metric on a scale from 1 to 5, in which 5
>         represents excellent and 1 represents unacceptable.  This metric
>         is defined as not including the effects of delay and can be
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 29]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>         compared to MOS scores obtained from listening quality (ACR)
>         tests. It is expressed as an integer in the range 10 to 50,
>         corresponding to MOS x 10.  For example, a value of 35 would
>         correspond to an estimated MOS score of 3.5.
> 
>         A value of 127 indicates that this parameter is unavailable.
> 
>    MOS-CQ: 8 bits
>         The estimated mean opinion score for conversational quality
>         (MOS-CQ) is defined as including the effects of delay and other
>         effects that would affect conversational quality.  The metric
>         may be calculated by converting an R factor determined according
>         to ITU-T G.107 [4] or ETSI TS 101 329-5 [2] into an estimated
>         MOS using the equation specified in G.107.  It is expressed as
>         an integer in the range 10 to 50, corresponding to MOS x 10, as
>         for MOS-LQ.
> 
>         A value of 127 indicates that this parameter is unavailable.
> 
> 4.7.6 Configuration Parameters
> 
>    Gmin: 8 bits
>         The gap threshold.  This field contains the value used for this
>         report block to determine if a gap exists.  The recommended
>         value of 16 corresponds to a burst period having a minimum
>         density of 6.25% of lost or discarded packets, which may cause
>         noticeable degradation in call quality; during gap periods, if
>         packet loss or dis card occurs, each lost or discarded packet
>         would be preceded by and followed by a sequence of at least 16
>         received non-discarded packets.  Note that lost or discarded
>         packets that occur within Gmin packets of a report being
>         generated may be reclassified as being part of a burst or gap in
>         later reports.  ETSI TS 101 329-5 [2] defines a computationally
>         efficient algorithm for measuring burst and gap density using a
>         packet loss/discard event driven approach.  This algorithm is
>         reproduced in Appendix A.2 of the present document.  Gmin MUST
>         not be zero and MUST be provided.
> 
> receiver configuration byte (RX config): 8 bits
>         This byte consists of the following fields:
> 
> 
>          0 1 2 3 4 5 6 7
>         +-+-+-+-+-+-+-+-+
>         |PLC|JBA|JB rate|
>         +-+-+-+-+-+-+-+-+
> 
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 30]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>         packet loss concealment (PLC): 2 bits
>              Standard (11) / enhanced (10) / disabled (01) / unspecified
>              (00).  When PLC = 11 then a simple replay or interpolation
>              algorithm is being used to fill-in the missing packet.
>              This is typically able to conceal isolated lost packets
>              with loss rates under 3%.  When PLC = 10 then an enhanced
>              interpolation algorithm is being used.  This would
>              typically be able to conceal lost packets for loss rates of
>              10% or more.  When PLC = 01 then silence is inserted in
>              place of lost packets.  When PLC = 00 then no information
>              is available concerning the use of PLC however for some
>              CODECs this may be inferred.
> 
>         jitter buffer adaptive (JBA): 2 bits
>              Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown
>              (00).  When the jitter buffer is adaptive then its size is
>              being dynamically adjusted to deal with varying levels of
>              jitter.  When non-adaptive, the jitter buffer size is
>              maintained at a fixed level.  When either adaptive or non-
>              adaptive modes are specified then the jitter buffer size
>              parameters below MUST be specified.
> 
>         jitter buffer rate (JB rate): 4 bits
>              J = adjustment rate (0-15). This represents the
>              implementation specific adjustment rate of a jitter buffer
>              in adaptive mode. This parameter is defined in terms of the
>              approximate time taken to fully adjust to a step change in
>              peak to peak jitter from 30 ms to 100 ms such that:
> 
>              adjustment time = 2 * J * frame size (ms)
> 
>              This parameter is intended only to provide a guide to the
>              degree of "aggressiveness" of a an adaptive jitter buffer
>              and may be estimated. A value of 0 indicates that the
>              adjustment time is unknown for this implementation.
> 
> 4.7.7 Jitter Buffer Parameters
> 
>    jitter buffer nominal size in frames (JB nominal): 8 bits
>         This is the current nominal fill point within the jitter buffer,
>         which corresponds to the nominal jitter buffer delay for packets
>         that arrive exactly on time.  This parameter MUST be provided
>         for both fixed and adaptive jitter buffer implementations.
> 
>    jitter buffer maximum size in frames (JB maximum): 8 bits
>         This is the current maximum jitter buffer level corresponding to
>         the earliest arriving packet that would not be discarded.  In
>         simple queue implementations this may correspond to the nominal
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 31]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>         size. In adaptive jitter buffer implementations this value may
>         dynamically vary up to JB abs max (see below).  This parameter
>         MUST be provided for both fixed and adaptive jitter buffer
>         implementations.
> 
>    jitter buffer absolute maximum size in frames (JB abs max): 8 bits
>         This is the absolute maximum size that the adaptive jitter
>         buffer can reach under worst case jitter conditions.  This
>         parameter MUST be provided for adaptive jitter buffer
>         implementations and its value MUST be set to JB maximum for
>         fixed jitter buffer implementations.
> 
> 5. IANA Considerations
> 
>    This document defines a new RTP packet type, the extended report (XR)
>    type, within the existing Internet Assigned Numbers Authority (IANA)
>    registry of RTP RTCP Control Packet Types.  This document also
>    defines a new IANA registry: the registry of RTP XR Block Types.
>    Within this new registry, this document defines an initial set of
>    seven block types and describes how the remaining types are to be
>    allocated.
> 
> 5.1 XR Packet Type
> 
>    The IANA SHALL register the RTP extended report (XR) packet defined
>    by this document as packet type 207 in the registry of RTP RTCP
>    Control Packet types (PT).
> 
> 5.2 RTP XR Block Type Registry
> 
>    The IANA SHALL create the RTP XR Block Type Registry to cover the
>    name space of the extended report block type (BT) field specified in
>    Section 3 of this document.  The BT field contains eight bits,
>    allowing 256 values.  The IANA SHALL manage the RTP XR Block Type
>    Registry according to the Specification Required policy of RFC 2434
>    [6].  Future specifications SHOULD attribute block type values in
>    strict numeric order following the values attributed in this
>    document:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 32]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    BT  name
>    --  ----
>     1  Loss RLE Report Block
>     2  Duplicate RLE Report Block
>     3  Timestamp Report Block
>     4  Statistics Summary Report Block
>     5  Receiver Timestamp Report Block
>     6  DLRR Report Block
>     7  VoIP Metrics Report Block
> 
> 
>    Furthermore, future specifications SHOULD avoid the values 0 and 255.
>    Doing so facilitates packet validity checking, since all-zeros and
>    all-ones are values that might commonly be found in ill-formed
>    packets.
> 
> 6. Security Considerations
> 
>    This document extends the RTCP reporting mechanism.  The security
>    considerations that apply to RTCP reports also apply to XR reports.
>    This section details the additional security considerations that
>    apply to the extensions.
> 
>    The extensions introduce heightened confidentiality concerns.
>    Standard RTCP reports contain a limited number of summary statistics.
>    The information contained in XR reports is both more detailed and
>    more extensive (covering a larger number of parameters).  The per-
>    packet information contained in Loss RLE, Duplicate RLE, and
>    Timestamp Report Blocks facilitates MINC inference of multicast
>    distribution trees for RTP data packets, and inference of link
>    characteristics such as loss and delay.  This inference reveals
>    information that might otherwise be considered confidential to
>    autonomous system administrators.  The VoIP Metrics Report Block
>    provides information on the quality of ongoing voice calls.  Though
>    such information might be carried in application specific format in
>    standard RTP sessions, making it available in a standard format here
>    makes it more available to potential eavesdroppers.
> 
>    No new mechanisms are introduced in this document to ensure
>    confidentiality.  Standard encryption procedures can be used when
>    confidentiality is a concern to end hosts.  Autonomous system
>    administrators concerned about the loss of confidentiality regarding
>    their networks can encrypt traffic, or filter it to exclude RTCP
>    packets containing the XR report blocks concerned.
> 
>    Any encryption or filtering of XR report blocks entails a loss of
>    monitoring information to third parties.  For example, a network that
>    establishes a tunnel to encrypt VoIP Report Blocks denies that
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 33]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    information to the service providers traversed by the tunnel.  The
>    service providers cannot then monitor or respond to the quality of
>    the VoIP calls that they carry, potentially creating problems for the
>    network's users.  As a default, XR packets SHOULD NOT be encrypted or
>    filtered.
> 
>    The extensions also make certain denial of service attacks easier.
>    This is because of the potential to create RTCP packets much larger
>    than average with the per packet reporting capabilities of the Loss
>    RLE, Duplicate RLE, and Timestamp Report Blocks.  Because of the
>    automatic bandwidth adjustment mechanisms in RTCP, if some session
>    participants are sending large RTCP packets, all participants will
>    see their RTCP reporting intervals lengthened, meaning they will be
>    able to report less frequently.  To limit the effects of large
>    packets, even in the absence of denial of service attacks,
>    applications SHOULD limit the size of XR report blocks and employ the
>    thinning techniques described in this document in order to fit
>    reports into the space available.
> 
> A. Algorithms
> 
> A.1 Sequence Number Interpretation
> 
>    This the algorithm suggested by Section 4.1 for keeping track of the
>    sequence numbers from a given sender.  It implements the accounting
>    practice required for the generation of Loss RLE Report Blocks.
> 
>    This algorithm keeps track of 16 bit sequence numbers by translating
>    them into a 32 bit sequence number space.  The first packet received
>    from a source is considered to have arrived roughly in the middle of
>    that space.  Each packet that follows is placed either ahead or
>    behind the prior one in this 32 bit space, depending upon which
>    choice would place it closer (or, in the event of a tie, which choice
>    would not require a rollover in the 16 bit sequence number).
> 
>    // The reference sequence number is an extended sequence number
>    // that serves as the basis for determining whether a new 16 bit
>    // sequence number comes earlier or later in the 32 bit sequence
>    // space.
>    u_int32 _src_ref_seq;
>    bool    _uninitialized_src_ref_seq;
> 
>    // Place seq into a 32-bit sequence number space based upon a
>    // heuristic for its most likely location.
>    u_int32 extend_seq(const u_int16 seq) {
> 
>            u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b;
>            if(_uninitialized_src_ref_seq) {
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 34]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>                    // This is the first sequence number received.  Place
>                    // it in the middle of the extended sequence number
>                    // space.
>                    _src_ref_seq                = seq | 0x80000000u;
>                    _uninitialized_src_ref_seq  = false;
>                    extended_seq                = _src_ref_seq;
>            }
>            else {
> 
>                    // Prior sequence numbers have been received.
>                    // Propose two candidates for the extended sequence
>                    // number: seq_a is without wraparound, seq_b with
>                    // wraparound.
>                    seq_a = seq | (_src_ref_seq & 0xFFFF0000u);
>                    if(_src_ref_seq < seq_a) {
>                            seq_b  = seq_a - 0x00010000u;
>                            diff_a = seq_a - _src_ref_seq;
>                            diff_b = _src_ref_seq - seq_b;
>                    }
>                    else {
>                            seq_b  = seq_a + 0x00010000u;
>                            diff_a = _src_ref_seq - seq_a;
>                            diff_b = seq_b - _src_ref_seq;
>                    }
> 
>                    // Choose the closer candidate.  If they are equally
>                    // close, the choice is somewhat arbitrary: we choose
>                    // the candidate for which no rollover is necessary.
>                    if(diff_a < diff_b) {
>                            extended_seq = seq_a;
>                    }
>                    else {
>                            extended_seq = seq_b;
>                    }
> 
>                    // Set the reference sequence number to be this most
>                    // recently-received sequence number.
>                    _src_ref_seq = extended_seq;
>            }
> 
>            // Return our best guess for a 32-bit sequence number that
>            // corresponds to the 16-bit number we were given.
>            return extended_seq;
>    }
> 
>    A.2 Example Burst Packet Loss Calculation.
> 
>    This is an algorithm for measuring the burst characteristics for the
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 35]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    VoIP Metrics Report Block (Section 4.7).  It is reproduced from ETSI
>    TS 101 329-5 [2].  The algorithm is event driven and hence extremely
>    computationally efficient.
> 
>    Given the following definition of states:
> 
> 
>    state 1 = received a packet during a gap
>    state 2 = received a packet during a burst
>    state 3 = lost a packet during a burst
>    state 4 = lost an isolated packet during a gap
> 
> 
>    The "c" variables below correspond to state transition counts, i.e.
>    c14 is the transition from state 1 to state 4. It is possible to
>    infer one of a pair of state transition counts to an accuracy of 1
>    which is generally sufficient for this application.
> 
>    "pkt" is the count of packets received since the last packet was
>    declared lost or discarded and "lost" is the number of packets lost
>    within the current burst.  "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.
> 
>    if(packet_lost) {
>            loss_count++;
>    }
>    if(packet_discarded) {
>            discard_count++;
>    }
>    if(!packet_lost && !packet_discarded) {
>            pkt++;
>    }
>    else {
>            if(pkt >= gmin) {
>                    if(lost == 1) {
>                            c14++;
>                    }
>                    else {
>                            c13++;
>                    }
>                    lost = 1;
>                    c11 += pkt;
>            }
>            else {
>                    lost++;
>                    if(pkt == 0) {
>                            c33++;
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 36]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>                    }
>                    else {
>                            c23++;
>                            c22 += (pkt - 1);
>                    }
>            }
>            pkt = 0;
>    }
> 
>    At each reporting interval the burst and gap metrics can be
>    calculated as follows.
> 
>    // Calculate additional transition counts.
>    c31 = c13;
>    c32 = c23;
>    ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;
> 
>    // Calculate burst and densities.
>    p32 = c32 / (c31 + c32 + c33);
>    if((c22 + c23) < 1) {
>            p23 = 1;
>    }
>    else {
>            p23 = 1 - c22/(c22 + c23);
>    }
>    burst_density = 256 * p23 / (p23 + p32);
>    gap_density = 256 * c14 / (c11 + c14);
> 
>    // Calculate burst and gap durations in ms
>    m = frameDuration_in_ms * framesPerRTPPkt;
>    gap_length = (c11 + c14 + c13) * m / c13;
>    burst_length = ctotal * m / c13 - lgap;
> 
>    /* calculate loss and discard densities */
>    loss_density = 256 * loss_count / ctotal;
>    discard_density = 256 * discard_count / ctotal;
> 
> Intellectual Property
> 
>    The IETF takes no position regarding the validity or scope of any
>    intellectual property or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; neither does it represent that it
>    has made any effort to identify any such rights.  Information on the
>    IETF's procedures with respect to rights in standards-track and
>    standards-related documentation can be found in BCP 11 [3].  Copies
>    of claims of rights made available for publication and any assurances
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 37]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    of licenses to be made available, or the result of an attempt made to
>    obtain a general license or permission for the use of such
>    proprietary rights by implementors or users of this specification can
>    be obtained from the IETF Secretariat.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights which may cover technology that may be required to practice
>    this standard.  Please address the information to the IETF Executive
>    Director.
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2003). All Rights Reserved.
> 
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works.  However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
> 
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assigns.
> 
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> Acknowledgements
> 
>    We thank the following people: Colin Perkins, Steve Casner, and
>    Henning Schulzrinne for their considered guidance; Sue Moon for
>    helping foster collaboration between the authors; Magnus Westerlund
>    for his detailed comments; Mounir Benzaid for drawing our attention
>    to the reporting needs of MLDA; and Dorgham Sisalem and Adam Wolisz
>    for encouraging us to incorporate MLDA block types.
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 38]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
> Contributors
> 
>    The following people are the authors of this document:
> 
>    Kevin Almeroth, UCSB
>    Ramon Caceres, ShieldIP
>    Alan Clark, Telchemy
>    Robert Cole, AT&T Labs
>    Nick Duffield, AT&T Labs-Research
>    Timur Friedman, Paris 6
>    Kaynam Hedayat, Brix Networks
>    Kamil Sarac, UT Dallas
> 
>    The principal people to contact regarding the individual report
>    blocks described in this document are as follows:
> 
> 
>    sec. report block                     principal contributors
>    ---- ------------                     ----------------------
>    4.1  Loss RLE Report Block            Friedman, Caceres, Duffield
>    4.2  Duplicate RLE Report Block       Friedman, Caceres, Duffield
>    4.3  Timestamp Report Block           Friedman, Caceres, Duffield
>    4.4  Statistics Summary Report Block  Almeroth, Sarac
>    4.5  Receiver Timestamp Report Block  Friedman
>    4.6  DLRR Report Block                Friedman
>    4.7  VoIP Metrics Report Block        Clark, Cole, Hedayat
> 
> 
> Authors' Addresses
> 
>    Kevin Almeroth <[email-masked]>
>    Department of Computer Science
>    University of California
>    Santa Barbara, CA 93106 USA
> 
>    Ramon Caceres <[email-masked]>
>    ShieldIP, Inc.
>    11 West 42nd Street, 31st Floor
>    New York, NY 10036 USA
> 
>    Alan Clark <[email-masked]>
>    Telchemy Incorporated
>    3360 Martins Farm Road, Suite 200
>    Suwanee, GA 30024 USA
>    Tel: +1 770 614 6944
>    Fax: +1 770 614 3951
> 
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 39]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    Robert Cole <[email-masked]>
>    AT&T Labs
>    330 Saint Johns Street,
>    2nd Floor
>    Havre de Grace, MD 21078 USA
>    Tel: +1 410 939 8732
>    Fax: +1 410 939 8732
> 
>    Nick Duffield <[email-masked]>
>    AT&T Labs-Research
>    180 Park Avenue, P.O. Box 971
>    Florham Park, NJ 07932-0971 USA
>    Tel: +1 973 360 8726
>    Fax: +1 973 360 8050
> 
>    Timur Friedman <[email-masked]>
>    Universite Pierre et Marie Curie (Paris 6)
>    Laboratoire LiP6-CNRS
>    8, rue du Capitaine Scott
>    75015 PARIS France
>    Tel: +33 1 44 27 71 06
>    Fax: +33 1 44 27 74 95
> 
>    Kaynam Hedayat <[email-masked]>
>    Brix Networks
>    285 Mill Road
>    Chelmsford, MA 01824 USA
>    Tel: +1 978 367 5600
>    Fax: +1 978 367 5700
> 
>    Kamil Sarac <[email-masked]>
>    Department of Computer Science (ES 4.207)
>    Eric Jonsson School of Engineering & Computer Science
>    University of Texas at Dallas
>    Richardson, TX 75083-0688 USA
>    Tel: +1 972 883 2337
>    Fax: +1 972 883 2349
> 
> References
> 
>    The references are divided into normative references and non-
>    normative references.
> 
> Normative References
> 
>    [1] S. Bradner, "Key words for use in RFCs to indicate requirement
>    levels," BCP 14, RFC 2119, IETF, March 1997.
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 40]
> 
> draft-ietf-avt-rtcp-report-extns-02.txt                  24 January 2003
> 
> 
>    [2] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI
>    TS 101 329-5 V1.1.1 (2000-11), November 2000.
> 
>    [3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF
>    Standards Process," best current practice BCP 11, RFC 2028, IETF,
>    October 1996.
> 
>    [4] ITU-T, "The E-Model, a computational model for use in
>    transmission planning," Recommendation G.107 (05/00), May 2000.
> 
>    [5] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2,
>    RFC 1700, IETF, October 1994.
> 
>    [6] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
>    Considerations Section in RFCs," best current practice BCP 26, RFC
>    2434, IETF, October 1998.
> 
>    [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
>    transport protocol for real-time applications," RFC 1889, IETF,
>    February 1996.
> 
> Non-Normative References
> 
>    [8] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J.
>    Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The
>    Use of End-to-End Multicast Measurements for Characterizing Internal
>    Network Behavior," IEEE Communications Magazine, May 2000.
> 
>    [9] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu
>    measurement infrastructures using RTP," Proc. IEEE Infocom 2002.
> 
>    [10] A. D. Clark, "Modeling the Effects of Burst Packet Loss and
>    Recency on Subjective Voice Quality," Proc. IP Telephony Workshop
>    2001.
> 
>    [11] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion
>    Control Framework for Heterogeneous Multicast Environments", Proc.
>    IWQoS 2000.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Friedman, Caceres, and Clark, eds.                             [Page 41]
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Feb 2003 11:16:50 +0100

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

---

From: "Timur Friedman" <[email-masked]>
Date: Sun, 23 Feb 2003 01:38:45 +0100

Hello Magnus,

[I address the signalling in this mail, and the timestamp block in a
subsequent mail.]

Getting a handle on the signalling for RTP XR reports is a major
priority.  Thank you for taking the initiative to think through how it
might be done.

I wonder, though, if it would be alright if we were to submit this as a
subsequent draft.  The concern is that introducing a significant change
at this point would make it difficult to proceed to working group last
call at San Francisco.

If not having signalling means we should not propose a standard then of
course we should wait.  But to my mind the extended reports are useful
in themselves, and a proposed standard will allow important work to go
forward.

Part of this work will entail applications that deploy these reports.
With the experience gained, we may be in a better position to say
exactly how signalling should be done than we are now.

Best regards,

Timur

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Thursday, February 20, 2003 11:17 AM
To: Timur Friedman
Cc: [email-masked]
Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt

Hi Timur,

gathering the information, and the bandwidth usage imposed by the
reporting.

TTL-flag

 

measurements.

...

---

From: "Timur Friedman" <[email-masked]>
Date: Sun, 23 Feb 2003 01:56:27 +0100

Hello Magnus,

[I address the comments relating to the timestamp report block in this
mail.  A previous mail addressed the comments relating to signalling.]

I agree that the timestamp report block potentially uses a large amount
of space, and could benefit from compression.  The method you propose
looks promising to me.  As in the case of signalling, though, I wonder
if we could not go forward with the present format and consider this for
a subsequent draft.

We proposed the Loss RLE block, for instance, after studying a number of
different compression techniques and concluding that run length
encoding, while not always offering the best ratio, was simple and could
reliably provide 5:1 compression over a fair range, given typical
observed loss patterns.

The current format for timestamps allows timestamps to be reported in a
simple and straightforward way.  It does not preclude a future format
that would show better compression characteristics.

Best regards,

Timur

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Thursday, February 20, 2003 11:17 AM
To: Timur Friedman
Cc: [email-masked]
Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt

Hi Timur,

...

  0                   1                   2                   3

Best Regards

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 24 Feb 2003 09:07:34 +0100

Hi Timur,

Comments below.

>at this point would make it difficult to proceed to working group last

I think that signaling is fundamental enough to this draft that it 
warrants to put it in directly. I would also not like to delay this 
draft. I would like to see it submitted to the IESG before May. I think 
that is still possible, especially if you would add this functionality 
in a update that you can submit before mondays cut-off date. You can 
take my text and rework it into suitable text for your draft. Then we 
can have a healthy discussion on this in San Francisco. Then after the 
meeting update the draft if any comments has been given. The have a WG 
last call in early April. There is no need to either ask or have WG last 
calls in relations to meetings. It might even be better as people will 
have more time to read the document.

In my opinion the author of a draft can very much effect the time that a 
draft takes to finish. You can shave of many weeks by simple being quick 
to reply and create updates when needed. Then ensuring that the WG 
chairs perform there work and makes last calls, send it to IESG, etc. 
also speeds things up.

>in themselves, and a proposed standard will allow important work to go
Yes, they are useful in applications that are of more conversational 
type. In these you can detect that the other party implements and send 
them. Then you can also send them. However in applications like 
on-demand streaming where media only flows one way it is not possible in 
a sensible way to make the receiver application aware of the servers 
desire to receive XR reports. Sending empty XR packets just to indicate 
support for XR formats seems wasteful of bandwidth.

Best Regards

Magnus Westerlund

---

From: "Timur Friedman" <[email-masked]>
Date: Mon, 24 Feb 2003 19:44:04 +0100

Hello Magnus,

> have more time to read the document.

There is no question in my mind that it would be a plus to specify SDP
signalling for RTP XR reports.  Of course until the precise form is
settled, there is nothing to stop applications from experimenting with
different signalling approaches.

My hesitation is whether the signalling text that you suggest is settled
enough to paste into the document between now and the Monday deadline.
We should really solicit the opinions of others on the list.  Have a
number of people experienced in the issues surrounding signalling had a
chance to go over the text and say that it is solid in its present form?

Regards,

Timur

---

From: "Alan Clark" <[email-masked]>
Date: Mon, 24 Feb 2003 14:27:48 -0500

Magnus' suggestion of providing a means for signalling to indicate that RTP
XR reports are required, the type and frequency of report, is a useful one.
I would suggest however that:

(i) This would be useful for a variety of different feedback mechanisms -
including RTP XR, RTCP and potentially others

(ii) There may be other protocols than SDP that would be more appropriate
for negotiating feedback in different applications.

These would both seem to suggest that it may be preferable to develop such
functionality but to keep it independent from RTP XR.  We should also review
the RTP XR draft to ensure that it is amenable to being negotiated.

The new draft could cover the following:-

- general framework for real time feedback
- reference to available report types
  - RTCP
  - RTP XR
  - video?
  - .....
- protocol independent model for report negotiation
- specific protocol implementations
  - SDP
  - SIP?
  - H.xxx?
  -

As Magnus comments, there are applications such as streaming which have
particular requirements.  We need to consider other applications such as
conferencing, multicast, broadcast.... to see what would make sense (e.g. in
a broadcast application would you still want to negotiate feedback with a
sample population of receivers?).  Trying to cover the range of potential
applications within the RTP XR draft could make it overly complicated.

Regards

Alan Clark
Telchemy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Timur
Friedman
Sent: Monday, February 24, 2003 1:44 PM
To: 'Magnus Westerlund'
Cc: [email-masked]
Subject: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt

Hello Magnus,

Regards,

Timur