Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, The IESG <firstname.lastname@example.org>, email@example.com, David Black <firstname.lastname@example.org>, Wesley Eddy <email@example.com> Subject: Protocol Action: 'Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME' to Proposed Standard (draft-ietf-tsvwg-rlc-fec-scheme-16.txt) The IESG has approved the following document: - 'Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME' (draft-ietf-tsvwg-rlc-fec-scheme-16.txt) as Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Mirja Kühlewind and Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/
Technical Summary This document describes two fully-specified Forward Erasure Correction (FEC) Schemes for Sliding Window Random Linear Codes (RLC), one for RLC over GF(2) (binary case), a second one for RLC over GF(2^^8), with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window FEC codes. These sliding window FEC codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these sliding window FEC codes offer key advantages with real-time flows in terms of reduced FEC-related latency while often providing improved packet erasure recovery capabilities. Working Group Summary This document is a companion to draft-ietf-tsvwg-fecframe-ext, which is an update to the FECFRAME work in RFC 6363. RFC 6363 was a product of the former FECFRAME working group, which closed several years ago. FECFRAME was in the TSV area. When several original FECFRAME participants proposed updates/extensions to support new types of codes (with benefits for some real world applications), between the Area Directors and TSVWG, it was agreed that the work should be done in TSVWG, and two documents including this one were adopted. Several FECFRAME participants are either authors/editors listed on the documents, or participated in reviews. Other than this history, there were no other significant issues or events of interest in the working group process on this document. Document Quality There have been implementations. The implementations were reported to the working group, and the documents benefited from the implementation and testing experience. Personnel The document shepherd is Wesley Eddy (firstname.lastname@example.org), and the responsible AD is Magnus Westerlund.