Subject: [Fecframe] Backward compatibility of the 1D/2D draft with RFC 2733, RFC 5109 and SMPTE 2022-1

From: "Ali Begen (abegen)" <[email-masked]>
Date: Thu, 13 Mar 2008 17:41:04 -0700

Hi everyone,

On Monday, there were questions raised regarding the backward
compatibility of the scheme discussed in
draft-begen-fecframe-1d2d-parity-scheme-00 with RFC 2733, 5109 and SMPTE
2022-1.

Basically, this draft is not backward compatible with these prior
documents. The way the FEC is computed (i.e., XOR operation) is the
same, but the headers/fields we are using are different.

I'll provide the main reasoning for each document. For any questions,
please post them to the mail list.

RFC 2733:
- RFC 5109 obsoleted RFC 2733. So, 2733 is already an old document. 

RFC 5109:
- RFC 5109 provides protection at different protection lengths and
levels, which may provide partial recovery of a missing packet. This is
not the intention in our draft.
- RFC 5109 uses a bitmap to convey the association information between
the repair and source packets. This bitmap consists of 16 bits (by
default) or 48 bits (if extended). That is, a repair packet may be
associated with source packets whose seqnums can be at most in the range
of [SN base, SN base + 48). As one could imagine, this is severely
limiting and is insufficient to handle large block sizes. 

SMPTE 2022-1:
Pro-MPEG CoP3 r2 document was an old document and was based on RFC 2733.
When SMPTE decided to update this spec, they made some changes but the
SMPTE doc is still based on RFC 2733 in many ways. This introduces
several inefficiencies.

More Reasons:
- SMPTE doc does not use the SSRC field (they set to zero) in the RTP
header of the repair packets. It does not use the timestamp field in the
RTP header, either. In contrast, we use these fields for good.
- SMPTE doc extends the already obsoleted RFC 2733 (by setting the E
bit).  
- SMPTE doc carries over the overhead of the bitmap mask field from
2733, although it doesn't use it. It is set to zero. 
- Several other fields, which are actually not essential.

Note that SMPTE doc does not use the bitmap (the bitmap field still
exists, though) for indicating associations between the source and
repair packets, but the document signals the number of columns (L) and
rows (D) in the FEC header. Each value (L and D) is limited to 8 bits,
so they have to be smaller than 256. While this is way better than what
RFC 5109 offers, 255 may be limiting for the FEC framework when high
bitrate source flows are to be protected and/or a group of source flows
are protected together. Note that higher aggregated bitrate means larger
block sizes (in terms of number of packets in the block) even when the
size of the block in terms of time is not that large. 

In summary, there are improvements in the SMPTE document over the
previous documents, but it still inherits many legacy stuff from those
earlier docs. Furthermore, it still has limitations on the source block
sizes. We considered these issues carefully and decided to make our
draft better by not being backward compatible. 

It is the expectation of the authors and the WG that this new format for
the parity FEC codes will satisfy the needs of the FEC Framework and the
emerging high-bitrate applications. 

It is also expected that any future FEC specification that is using the
parity FEC codes will use this format to be compatible with this draft.
Of course, we are still in the first version of this draft and would
welcome any suggestions. So, please speak up. 

I am hoping this email will address the questions raised in the meeting.

Thanks,
-acbegen

PS This information regarding backward compatibility will also be
incorporated into the draft in the next revision.
_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe

---

From: Mark Watson <[email-masked]>
Date: Tue, 18 Mar 2008 10:49:40 -0700

Ali,

Thanks for these clarifications.

> emerging high-bitrate applications.

This may be the authors expectation, but this wasn't discussed at the WG.

In FECFRAME we do not have a charter to make judgements/recommendations
about the suitability of FEC Schemes for given applications and the FEC
Framework doesn't have "needs" in this regard.

Of course it's correct that your scheme fits the requirements for an FEC
Scheme within the Framework, but this is all.

As for high-bitrate applications, your claim is highly debatable. This
particular code would behave very badly in such a setting as the larger
block size would not bring the efficiency improvements one would normally
expect with larger blocks and comes with significant restrictions on the
overheads and hence loss rates/patterns supported.

...Mark

---

From: "Greg Shepherd" <[email-masked]>
Date: Tue, 18 Mar 2008 11:27:01 -0700

>  overheads and hence loss rates/patterns supported.

..which brings us back outside the scope of the WG in discussing
suitability of an FEC Scheme. ;-)

From what I understand, the question seems to be:
Does the framework as defined today currently support this scheme?

Thanks,
Greg

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Tue, 18 Mar 2008 11:35:03 -0700

Hi Mark,

Let me clarify a few points here. My apologies for miscommunication, if
any.

> > It is the expectation of the authors and the WG that this 
> new format 
> > for the parity FEC codes will satisfy the needs of the FEC 
> Framework 
> > and the emerging high-bitrate applications.
> 

We are not claiming that the parity FEC codes are the most suitable or
the most efficient codes available. We are simply claiming the parity
FEC codes satisfy the reqs of the framework and compared to the previous
specs (the ones cited below), we believe this spec is more friendly with
the high-bitrate applications. If somebody wants to use parity FEC
codes, this spec should be preferred for the reasons listed below.

Yes, it is the author's expectation but I also recall that the WG
previously agreed on defining a particular FEC scheme only once
regardless of whether the same code would be used in a hybrid fashion
with other codes. Correct me if I am wrong here.

> In FECFRAME we do not have a charter to make 
> judgements/recommendations about the suitability of FEC 
> Schemes for given applications and the FEC Framework doesn't 
> have "needs" in this regard.

In the draft, we can list the scenarios where a particular code (e.g.,
row vs column, 1-D vs. 2-D) works better. I don't see any problem with
this at all.

> Of course it's correct that your scheme fits the requirements 
> for an FEC Scheme within the Framework, but this is all.
> 
> As for high-bitrate applications, your claim is highly 
> debatable. This particular code would behave very badly in 
> such a setting as the larger block size would not bring the 
> efficiency improvements one would normally expect with larger 
> blocks and comes with significant restrictions on the 

Again, we are not claiming that the parity FEC codes are the best
available codes in the market. What we are claiming is that our spec
works better (more suitable and/or friendly) than the previous specs
that are cited below. 

I did not do comparison with any other FEC code. No need to read more
than it is intended.

Thanks,
-acbegen

> > draft-begen-fecframe-1d2d-parity-scheme-00 with RFC 2733, 5109 and 
> > SMPTE 2022-1.
> > 
> > levels, which may provide partial recovery of a missing 
> packet. This 
> > is not the intention in our draft.
> > associated with source packets whose seqnums can be at most in the 
> > range of [SN base, SN base + 48). As one could imagine, this is 
> > severely limiting and is insufficient to handle large block sizes.
> > 
> > SMPTE 2022-1:
> > header of the repair packets. It does not use the timestamp 
> field in 
> > the RTP header, either. In contrast, we use these fields for good.
> > so they have to be smaller than 256. While this is way better than 
> > what RFC 5109 offers, 255 may be limiting for the FEC 
> framework when 
> > high bitrate source flows are to be protected and/or a 
> group of source 
> > flows are protected together. Note that higher aggregated bitrate 
> > means larger block sizes (in terms of number of packets in 
> the block) 
> > even when the size of the block in terms of time is not that large.
> > 
> > earlier docs. Furthermore, it still has limitations on the source 
> > block sizes. We considered these issues carefully and 
> decided to make 
> > our draft better by not being backward compatible.
> > 
> > It is the expectation of the authors and the WG that this 
> new format 
> > for the parity FEC codes will satisfy the needs of the FEC 
> Framework 
> > and the emerging high-bitrate applications.
> > 
> > It is also expected that any future FEC specification that is using 
> > the parity FEC codes will use this format to be compatible 
> with this draft.