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

Download Report

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 ([email protected])
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 ([email protected])
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 ([email protected])
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 ([email protected])
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 ([email protected])
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 ([email protected])
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 ([email protected])
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 ([email protected])
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 ([email protected])
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 ([email protected])
11
Next Steps
• Shall we make this draft a WG item?
Ali C. Begen ([email protected])
12