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

1-D and 2-D Parity FEC Scheme
draft-begen-fecframe-1d2d-parity-scheme-00
IETF 71 – March 2008
Ali C. Begen and Rajiv Asati
{abegen, rajiva}@cisco.com
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)
Ali C. Begen (abegen@cisco.com)
2
1-D and 2-D Parity FEC
2
3
R1
4
5
6
R2
7
8
9
10
11
12
D
XOR
1
R3
R4
Repair Packets
L
•
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
XOR
– Overhead = 1 / L
C1
C2
C3
•
2-D Column + Row FEC
– Overhead = (D+L)/(DxL)
Repair Packets
Ali C. Begen (abegen@cisco.com)
3
XOR
1-D and 2-D Parity FEC Limitations
1-D Column FEC fails!
1-D Row FEC would work
XOR
XOR
XOR
1-D Row FEC fails!
1-D Column FEC would work
Ali C. Begen (abegen@cisco.com)
Both 1-D and 2-D
FEC fails!
Packet Loss
4
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
Ali C. Begen (abegen@cisco.com)
5
Source FEC Payload ID
• Each source packet MUST contain the information that
identifies
– Source block
– Packet’s 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
Ali C. Begen (abegen@cisco.com)
6
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
| `--+------------------------+
+--------------------------+
Ali C. Begen (abegen@cisco.com)
7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|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
Ali C. Begen (abegen@cisco.com)
8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|I|P|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 won’t be limited to block sizes of 255 x 255
Ali C. Begen (abegen@cisco.com)
9
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
Ali C. Begen (abegen@cisco.com)
10
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)
Ali C. Begen (abegen@cisco.com)
11
Next Steps
• Shall we make this draft a WG item?
Ali C. Begen (abegen@cisco.com)
12