Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FEC Object Transmission Information format for FEC Encoding ID 5 appears to deviate from RFC 5510 #17

Open
ronald-intvelt opened this issue Jan 25, 2021 · 2 comments

Comments

@ronald-intvelt
Copy link

Per RFC 5510, section 5.2, the format of the EXT_FTI header extension for FEC Encoding ID 5 is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   HET = 64    |    HEL = 3    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                      Transfer Length (L)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Encoding Symbol Length (E)  | MaxBlkLen (B) |     max_n     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where max_n is defined as:

the maximum number of encoding symbols generated for any source block

According to section 6.2, max_n = ceil (B / CR) where CR is the code rate.

However, member function SetFecNumParity() of class NormFtiExtension5 appears to write the number of generated repair symbols (n_r in RFC 5510 notation) into this field of the FTI extension header instead.

@bebopagogo
Copy link
Collaborator

Ron - thank you for catching that (and good to hear from you ... I hope all is well as it can be in these crazy times). I guess I assumed "encoding symbols" meant parity symbols without paying close attention to the specification. I will make a note to address that. I will also look to see if I made the same mistake elsewhere. However, it will impact interoperability for existing NORM deployments. I suspect current use cases are generally deploying any NORM code updates uniformly, so I can probably still get away with making the change. It's definitely good to catch it now in case NORM ever gets more popular.

@bebopagogo
Copy link
Collaborator

bebopagogo commented Feb 21, 2021

It looks like I was consistent with my mistake and the other FEC Encoding ID object transport information (OTI) fields should be corrected similarly. In fact, this actually points to an error in RFC 5740 where it uses the nomenclature "fec_num_parity" to describe the (OTI) field that corresponds to maximum encoding symbols (max_n). We should probably submit an errata for RFC 5740 to correct this there, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants