Subject: [AVTCORE] ECN for RTP: Packet loss counters

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Apr 2011 13:59:02 +0200

Hi,

As discussed in Prague the preference to resolve the issue with packet
loss counter saturation was to redefine the counters. We have a proposal
for that ready. There is one potential issue that we in addition would
like to get feedback on. Namely if the packet format with bad alignment
is to ugly and if it is worth spending 4 more bytes on this to get
alignment between the XR and RTCP feedback packet.

The XR packet is proposed to look like this:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SSRC of Media Sender                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECT (0) Counter                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECT (1) Counter                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | CE Counter                    | not-ECT Counter               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Loss Packet Counter           | Duplication Counter           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Variant 1 of the Feedback packet:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extended Highest Sequence Number              | ECT (0) Ctr   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECT (0) Counter cont. | ECT (1) Counter                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | CE Counter                    | not-ECT Counter               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Loss Packet Counter           | Duplication Counter           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Variant 2 of the feedback packet:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extended Highest Sequence Number                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECT (0) Counter                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECT (1) Counter                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | CE Counter                    | not-ECT Counter               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Loss Packet Counter           | Duplication Counter           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So variant 2 uses 4 bytes more. But has the advantage of being aligned
with the XR format and not require bit-shifts to get to the values of
ECT fields.

I think going with alternative 2 is preferable.

The field definitions are for variant 1:

   ECT(0) Counter:  The cumulative number of RTP packets received from
      this SSRC since the receiver joined the RTP session that had an
      ECN field value of ECT(0).  The receiver should keep track of this
      value using a local representation that is at least 32-bits, and
      only include the 20-bits with least significance.  In other words,
      the field will wrap if more than 1048576 packets have been
      received.

   ECT(1) Counter:  The cumulative number of RTP packets received from
      this SSRC since the receiver joined the RTP session that had an
      ECN field value of ECT(1).  The receiver should keep track of this
      value using a local representation that is at least 32-bits, and
      only include the 20-bits with least significance.  In other words,
      the field will wrap if more than 1048576 packets have been
      received.

   CE Counter:  The cumulative number of RTP packets received from this
      SSRC since the receiver joined the RTP session that were ECN-CE
      marked, including ECN-CE marks in any duplicate packets.  The
      receiver should keep track of this value using a local
      representation that is longer than 16-bits, and only include the
      16-bits with least significance.  In other words, the field will
      wrap if more than 65535 packets has been received.

   not-ECT Counter:  The cumulative number of RTP packets received from
      this SSRC since the receiver joined the RTP session that had an
      ECN field value of not-ECT.  The receiver should keep track of
      this value using a local representation that is longer than 16-
      bits, and only include the 16-bits with least significance.  In
      other words, the field will wrap if more than 65535 packets have
      been received.

   Lost Packets Counter:  The cumulative number of RTP packets that the
      receiver expected to receive minus the number of packets it
      actually received that are not a duplicate of an already received
      packet, from this SSRC since the receiver joined the RTP session.
      Note that packets that arrive late are not counted as lost, and
      the loss may be negative if there are duplicates.  The receiver
      should keep track of this value using a local representation that
      is longer than 16-bits, and only include the 16-bits with least
      significance.  In other words, the field will wrap if more than
      65535 packets have been received.

   Duplication Counter:  The cumulative number of RTP packets received
      that are a duplicate of an already received packet from this SSRC
      since the receiver joined the RTP session.  The receiver should
      keep track of this value using a local representation that is
      longer than 16-bits, and only include the 16-bits with least
      significance.  In other words, the field will wrap if more than
      65535 packets have been received.

Comments appreciated

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------