1-D and 2-D Parity FEC Scheme draft-begen-fecframe-1d2d-parity-scheme-00 IETF 71

1
1-D and 2-D Parity FEC Scheme draft-begen-fecframe
-1d2d-parity-scheme-00IETF 71 March 2008

• Ali C. Begen and Rajiv Asati
• abegen, rajiva_at_cisco.com

2
Introduction

• 1-D and 2-D parity codes are systematic FEC codes
  of decent complexity that provide protection
  against
• Bursty losses
• Random losses
• This document
• Describes a Fully-Specified FEC Scheme for the
  1-D and 2-D parity codes
• Specifies an RTP payload format for the FEC that
  is generated by the 1-D and 2-D parity codes from
  an RTP source media
• The FEC defined in this document is not backward
  compatible with RFC 5109 (or SMPTE 2022-1)

3
1-D and 2-D Parity FEC

• Source block size D x L
• 1-D Column FEC (for Bursty Losses)
• Each column produces a single packet
• Overhead 1 / D
• L-packet duration should be larger than the
  (target) burst duration
• 1-D Row FEC (for Random Losses)
• Each row produces a single packet
• Overhead 1 / L
• 2-D Column Row FEC
• Overhead (DL)/(DxL)

L
1
2
3
R1
4
5
6
R2
XOR
D
Repair Packets
7
8
9
R3
10
11
12
R4
XOR
C1
C2
C3
Repair Packets
4
1-D and 2-D Parity FEC Limitations
XOR
XOR
XOR
1-D Column FEC fails! 1-D Row FEC would work
Both 1-D and 2-D FEC fails!
XOR
1-D Row FEC fails! 1-D Column FEC would work
Packet Loss
5
FEC Framework Architecture Minor Tweaks
Application Layer
Content Delivery Protocol (CDP)
FEC Config
Transport Protocol
FEC Framework
FEC Scheme
Transport Layer (UDP, DCCP, etc)
Network Layer (IP)
Data Link Layer
6
Source FEC Payload ID

• Each source packet MUST contain the information
  that identifies
• Source block
• Packets relative position within the source
  block
• We use RTP streams as the source flows
• Unique sequence numbers in the RTP headers
• No need to use the Explicit Source FEC Payload ID
  field
• Source packets are not modified
• Compatibility with non-FEC-capable receivers
• Usability of the same multicast group for all
  receivers

7
Repair FEC Payload ID

• Repair packets MUST contain information that
  identifies
• Source block they pertain to
• Relationship between the repair symbols and
  original source block

-------------------------- IP
Header --------------------------
Transport Header
,--------------------------
---------------------------' RTP
Header Repair FEC Payload ID
------------------------
---------------------------. FEC
Header Repair Symbols
--------------------------
--------------------------
8
RTP Header for Repair Packets
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 -----------
--------------------- V2P
X CC M PT Sequence number
--------------------
------------
Timestamp
------------------------
-------- Synchronization
source (SSRC) identifier

Contributing
source (CSRC) identifiers
....
----------------------
----------

• Marker Not used, set to 0
• Payload Type Introduced in this document
  (Requires IANA registration)
• Unrecognized payload types are discarded per RFC
  3550
• Sequence Number (SN) One higher for each
  subsequent packet
• Timestamp (TS) Set to the value of the media RTP
  clock at the instant the repair packet is
  transmitted
• SSRC Same as the SSRC value of the protected
  source RTP stream

9
FEC Header
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 -----------
--------------------- EIP
X CC M PT recovery SN base
--------------------
------------
TS recovery
------------------------
-------- Length recovery
Increment NA
------------------------
--------

• I bit Set to 0 for the column-FEC, and 1 for the
  row-FEC packets
• SN base Set to the lowest sequence number of
  those source packets protected by FEC
• Increment field Set to L for the column-FEC, and
  1 for the row-FEC packets
• NA field Set to D for the column-FEC, and L for
  the row-FEC packets
• Open Issue L and D are already specified in the
  FSSI. Can we skip the Increment and NA fields?
• ? We wont be limited to block sizes of 255 x 255

10
Configuration Information

• FEC Encoding ID Requires IANA registration ? 0
  or 1?
• FEC-Scheme-Specific Information
• L Number of columns of the source block
• D Number of rows of the source block
• Open Issue Shall we define sending arrangements?
  Can we generalize?
• ToP Type of the protection
• 0 for 1-D column-FEC protection
• 1 for 1-D row-FEC protection
• 2 for 2-D column and row-FEC protection
• 3 is reserved
• Open Issue Shall we consider code types other
  than XOR?
• ToF Type of the FEC data carried in the repair
  flow
• 0 for column FEC
• 1 for row FEC
• L, D and ToP are carried in SS-FSSI, and ToF is
  carried in RS-FSSI

11
FEC Encoding / Decoding

• FEC Encoding Repair Packet Construction
• RTP Header Regular RTP header for the repair
  packet
• FEC Header Provides protection for the RTP
  headers of the source packets
• Repair Symbols Provides protection for the RTP
  payloads of the source packets (Variable-length
  packets are OK)
• FEC Decoding Source Packet Reconstruction
• Step 1 Associating the source and repair packets
• Step 2 Recover the RTP header and the payload
• 2-D parity codes require iterative decoding (of
  the same algorithm used by the 1-D parity codes)

12
Next Steps

• Shall we make this draft a WG item?