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

Refine packet interleaving scheme #98

Closed
gavv opened this issue Aug 1, 2017 · 0 comments
Closed

Refine packet interleaving scheme #98

gavv opened this issue Aug 1, 2017 · 0 comments
Labels
postponed We decided to postpone the issue for an indefinite period

Comments

@gavv
Copy link
Member

gavv commented Aug 1, 2017

Last revised: Oct 2023

Problem

In sender pipeline, we have packet::Interleaver which can shuffle packets inside one FEC block. The idea is that this increases chances of successful packet recovery if some of the packets are lost.

However, quick tests showed that enabling interleaver does not help and sometimes even harms. I didn't look at it in great detail though.

Probably the problem is with the current shuffling algorithm. Or maybe the problem is that the interleaver has some additional latency that is not taken into account on the receiver.

Thus, this requires some research and testing. Here are some questions we need to answer:

  • What shuffling algorithm to use? Currently we shuffle all packets inside a block. Probably we should shuffle only repair packets. Probably we should shuffle packets across block boundaries.

  • Does the best shuffling algorithm depend on the FEC scheme? Do all FEC schemes need shuffling?

  • Are packet bursts harmful? Currently source packets are sent according to their timestamps one by one, but repair packets are sent all at once when they are generated at the end of a block. Probably we should insert some delays, or shuffle repair packets from the previous block with the source packets from the next block.

  • What is the latency introduced by interleaver and how should it be taken into account? Probably we need to increase the target queue size on the receiver if interleaver if enabled on sender.

Here is what RFC 6816 (LDPC FEC Scheme) says about packet ordering:

The way the FEC repair packets are transmitted is of high importance.
A good strategy, that works well for any kind of channel loss model,
consists in sending FEC repair packets in random order (rather than
in sequence) while FEC source packets are sent first and in sequence.
Sending all packets in a random order is another possibility, but it
requires that all repair symbols for a source block be produced
first, which adds some extra delay at a sender.

Solution

Do some tests and answer the questions above. Decide what interleaving algorithm we need and adjust packet::Interleaver accordingly. If makes sense, we also can support several interleaving schemes.

Info

About FEC:
https://roc-streaming.org/toolkit/docs/internals/fec.html

@gavv gavv changed the title Refine interleaving scheme Refine packet interleaving scheme Jul 4, 2019
@gavv gavv added the help wanted An important and awaited task but we have no human resources for it yet label Jul 4, 2019
@gavv gavv added networking Network I/O and algorithms algorithms Algorithms and data structures labels May 25, 2020
@gavv gavv removed the hacktoberfest label Dec 4, 2020
@gavv gavv added postponed We decided to postpone the issue for an indefinite period and removed enhancement help wanted An important and awaited task but we have no human resources for it yet networking Network I/O and algorithms algorithms Algorithms and data structures labels Jul 13, 2024
@gavv gavv closed this as completed Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
postponed We decided to postpone the issue for an indefinite period
Projects
Status: Done
Development

No branches or pull requests

1 participant