Internet Engineering Task Force                      Piers O'Hanlon
INTERNET DRAFT                                       UCL
June 29, 2009                                        Ken Carlberg
                                                     G11




              RTCP Extended Report for ECN Marked Packets
                <draft-carlberg-avt-rtcp-xr-ecn-01.txt>



Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the document
   authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal Provisions
   Relating to IETF Documents in effect on the date of publication of this
   document (http://trustee.ietf.org/license-info).  Please review these
   documents carefully, as they describe your rights and restrictions with
   respect to this document.

Abstract

   This document describes a Real-Time Control Protocol (RTCP) Extended
   Report (XR) containing information derived from the reception of
   Explicit Congestion Notification (ECN) marked packets.  This document is
   symbiotic with the approach described in [rtp-ecn], which presents one
   approach in establishing end-to-end ECN support for real-time sessions.



O'Hanlon, Carlberg     Expires December 29, 2009                [Page 1]

Internet Draft            ECN Extension Report             June 29, 2009


 Introduction

   Explicit Congestion Notification (ECN) is a dual-layer means of
   conveying the presence of congestion on an end-to-end manner without
   dropping packets.  The network layer indicates in hop-by-hop IP packets
   whether or not endpoints support ECN.  If yes, then if congestion exists
   along the downstream path, the IP packet is marked to indicate the
   congested condition to the endpoint.  At the upper layer has the dual
   responsibility of initially negotiating support for ECN as well as
   conveying the congested condition to the source endpoint.

   The initial realization of ECN was described in [rfc2481], and later
   obsoleted by [rfc3168].  In both cases, TCP was used as the upper layer
   transport protocol used to negotiate support for ECN during the
   establishment of an end-to-end connection and convey through the use of
   TCP acks the presence of congestion along the downstream path. The
   architecture presented [rfc3168] also opened the design to allow
   other upper layer protocols to be substitued for TCP.

1.1. Applicability

   This metric is believed to be applicable to all RTP applications
   which utilise ECN for congetsion control or other purposes. Additionally
   it may be utilised by monitoring systems.

. Design Approach

   Protocols such as SCTP and DCCP are natural candidates for support of
   ECN due to the stateful behavior.  However, UDP is stateless and not a
   viable candidate for accomplishing the state negotiation outlined in
   [rfc3168].  To compensate for this stateless feature, [rtp-ecn] proposes
   utilizing this RTCP XR extension to provide for an RTP minimal
   congestion control functionality. By employing Extended RTP Profile for
   Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
   [RFC 4585], it is possible to provide suitable timely feedback at the
   level necessary for base-line congestion control mechanisms.  This newly
   proposed XR follows the guidelines defined in [rfc3550] and [rfc3611].

 RTCP Block Extended Report:  ECN

   This block type permits detailed reporting upon the ECN marking of
   individual packets. As detailed above the ECN marking may be employed
   in a variety of ways. The information may also be utilised by
   monitoring systems.

   This reporting format utilises an approach closely aligned that in
   the Section 4.1 [rfc3611] Loss RLE report Block. The main difference
   with the ECN report block is that it reports both bits of the ECN field.



O'Hanlon, Carlberg     Expires December 29, 2009                [Page 2]

Internet Draft            ECN Extension Report             June 29, 2009


   The reason for this is so that the ECN statistics may be complete, by
   conveying all three codepoints; Congestion Experienced (CE), ECN-Capable
   Transport (ECT), and Not-ECT.

   The ECN Report Block has the following format:

    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=TBD    | 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 TBD.

   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 MUST be ignored by the receiver.

   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
         The length of this report block, including the header, in 32-
         bit words minus one.

   SSRC of source: 32 bits
         The SSRC of the RTP data packet source being reported upon by
         this report block.

   begin_seq: 16 bits
         The first sequence number that this block reports on.



O'Hanlon, Carlberg     Expires December 29, 2009                [Page 3]

Internet Draft            ECN Extension Report             June 29, 2009


   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 [RFC3611] (Section 4).  If the
         chunk is all zeroes, then it is a terminating null chunk.
         Otherwise, the left most bit of the chunk determines its type:
         0 for run length and 1 for bit vector.

. SDP Attribute

    The use of SDP to signal XR blocks is specified in [RFC3611], which
    provides for ease of extension. This section defines such an extension
    to provide for signalling of the ECN report block.

    An additional value, "ecn-rle", is defined for the existing "xr-format"
    parameter in RTCP XR attribute.

    rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF

    (as defined in RFC3611)

    xr-format = xr-format / ecn-rle

    ecn-rle = "ecn-rle" ["=" max-size]

. IANA Considerations

    This document creates a new block type within the IANA "RTCP XR Block
    Type Registry" called the ECN Metrics Block, and a new parameter xr-ecn
    within the "RTCP XR SDP Parameters Registry".

. Security Considerations

    The proposed RTCP XR report block introduces no new security
    considerations beyond those described in [RFC3611].  This block may
    provide per-packet statistics of downstream flows to the upstream
    source node.

. References

7.1.  Normative References

    [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
              Levels", BCP 14, RFC 2119, IETF, March 1997.

    [rfc3550] Schulzrinne, S., et al, "RTP: A Transport Protocol for Real-Time



O'Hanlon, Carlberg     Expires December 29, 2009                [Page 4]

Internet Draft            ECN Extension Report             June 29, 2009


              Applications", RFC 3550, IETF, July 2003

    [rfc3611] Friedman, T., et al, "RTP Control Protocol Extended Reports
              (RTCP XR)", RFC 3611, IETF, November 2003

    [rfc4585] Ott, J., et al, "Extended RTP Profile for Real-time Transport
              Control Protocol (RTCP) -Based Feedback (RTP/AVPF)", RFC 4585,
              IETF, July 2006

7.2  Informative References

    [rtp-ecn] Carlberg, K., P. O'Hanlon, "Explicit Notification Extension (ECN)
              Extension for RTP", Internet Draft, Work in Progress, Jun 2009

    [rfc2481] Ramakrishnan, S., S. Floyd, "A Proposal to Add Explicit Congestion
              Notification (ECN) to IP", RFC2481, IETF, January 1999

    [rfc3168] Ramakrishnan, S., et al, "The Addition of Explicit Congestion
              Notification (ECN) to IP", RFC3168, IETF, September 2001

Author's Addresses

   Piers O'Hanlon
   University College London
   Gower Street
   London, UK
   EMail: p.ohanlon@cs.ucl.ac.uk

   Ken Carlberg
   G11
   1601 Clarendon Blvd
   Arlington, VA, USA
   email: carlberg@g11.org.uk


















O'Hanlon, Carlberg     Expires December 29, 2009                [Page 5]