4 ms·

The title is misleading, when they say low-delay, really they mean over UDP instead of TCP. Their answer to video over UDP is a marginal efficiency gain in a fo

The title is misleading, when they say low-delay, really they mean over UDP instead of TCP. Their answer to video over UDP is a marginal efficiency gain in a forward error correction algorithm called RLNC. I haven't looked at RLNC, but it does seem to have some gains over more traditional FEC schemes. https://arxiv.org/abs/1802.04873 https://arxiv.org/abs/1802.04873

mortenvp 9y ago
As stated in the article, low delay is very hard to achieve over a reliable transport based on re-transmissions (such as TCP) - you have to wait for the loss to be detected and then the retransmitted packet to arrive. This is at least 3 x the latency of the link. Therefore if you really care about bounded low latency you need to use some form of erasure correcting algorithm (to provide upfront redundancy). In the article we simply show that substituting one "old" algorithm for a more modern one can give you much better efficiency (protection against packet loss) for the same bandwidth and latency/delay budget.
- tokyodude 9y ago
  I'm not disputing anything you mentioned but I just thought I'd point out that, at least in my experience, Soundcloud has close to instant response streaming audio. Pick a new song it starts streaming immediately. Que a different time and it jumps to that part immediately. Looking in the devtools it's pretty clear they are sending lots of small packets of audio over websockets rather than using the browser's built in audio streaming features as most music sites do. Of course it probably still has the TCP issue if there is an error but in general it's way more responsive than other music sites I've used.
  - thefourthchime 9y ago
    Audio is much easier to stream though. You need nearly no data to start streaming audio, and it's likely you're internet will keep up. The video is very different, the overhead is a lot more, 128kbit vs 2Mbps for example. On top of that, a video player will try to buffer ahead enough video to make sure you won't get and buffering later on, which means it needs to measure your bandwidth and try to guess how much. UDP can be nearly instant except in for b-frames, however if it's over UDP is probably over transport stream which has it's own buffering levels built in to make sure the decoder has a large enough buffer.
    - Selfcommit 9y ago
      So the overhead to begin a video stream is due to the size of video data? Would video behave generally more like audio data (could stream immidiately) if the typical user bandwidth was larger?
      - IshKebab 9y ago
        Yes. Although it still might not be as good due to TCP's slow start.
      - thefourthchime 9y ago
        In reality it's the size yes, but there is an inherent delay because of the way B-frames work. You'll need to buffer 2-3 frames worth 33ms each (for NTSC), so 66-99ms delay regardless of throughput. Audio doesn't have such a concept, you get 33ms worth of audio, you can play it right away. Of course, you can opt to not have b-frames and negate that issue.
        mgamache 9y ago
        most (all?) of the video codecs designed for low latency don't use b-frames for this reason.
        thefourthchime 9y ago
        It's just a setting, all codecs can optionally not use b-frames.
    - jacquesm 9y ago
      > Audio is much easier to stream though. This isn't even remotely true. The brain will happily interpolate all kinds of visual information that is missing which allows you to drop frames with abandon as long as you display an older frame instead of a 'blank space'. Audio isn't nearly as forgiving and even a relatively modest jitter or number of lost packets will result in an un-intelligible stream of audio. I've spent many years of my life pumping video and audio across the net, even when that wasn't yet considered normal (or even an intended purpose of the net), and I've rarely heard complaints about video quality. But audio delivery requires top notch connectivity, low latency and sufficient throughput if you intend to hold a conversation with someone that does not result in irritation. Video is far more forgiving.
- thefourthchime 9y ago
  Please help me understand then. I see RLNC compared to 2022 Single mode has the same overhead of 25%. When I compare the two using your tool at the end of the article, the only change I see is an improvement from 5% random loss to 25%. The burst loose stays the same. Correct?
  - mortenvp 9y ago
    Yes, you get a much better random loss protection with RLNC. So if you know that all your losses are bursts you may be able to live with 2022. Essentially the difference between the two algorithms are that with 2022 only a subset of your packets are protected by a redundancy packet (and you have to choose how to protect them), whereas with RLNC you can protect all available packets. If we leave the premise of this post (namely that we want to generate traffic in the same pattern as 2022) RLNC can even protect against longer bursts compared to 2022. Did that make sense?

mortenvp 9y ago

As stated in the article, low delay is very hard to achieve over a reliable transport based on re-transmissions (such as TCP) - you have to wait for the loss to be detected and then the retransmitted packet to arrive. This is at least 3 x the latency of the link. Therefore if you really care about bounded low latency you need to use some form of erasure correcting algorithm (to provide upfront redundancy). In the article we simply show that substituting one "old" algorithm for a more modern one can give you much better efficiency (protection against packet loss) for the same bandwidth and latency/delay budget.

tokyodude 9y ago
I'm not disputing anything you mentioned but I just thought I'd point out that, at least in my experience, Soundcloud has close to instant response streaming audio. Pick a new song it starts streaming immediately. Que a different time and it jumps to that part immediately. Looking in the devtools it's pretty clear they are sending lots of small packets of audio over websockets rather than using the browser's built in audio streaming features as most music sites do. Of course it probably still has the TCP issue if there is an error but in general it's way more responsive than other music sites I've used.
- thefourthchime 9y ago
  Audio is much easier to stream though. You need nearly no data to start streaming audio, and it's likely you're internet will keep up. The video is very different, the overhead is a lot more, 128kbit vs 2Mbps for example. On top of that, a video player will try to buffer ahead enough video to make sure you won't get and buffering later on, which means it needs to measure your bandwidth and try to guess how much. UDP can be nearly instant except in for b-frames, however if it's over UDP is probably over transport stream which has it's own buffering levels built in to make sure the decoder has a large enough buffer.
  - Selfcommit 9y ago
    So the overhead to begin a video stream is due to the size of video data? Would video behave generally more like audio data (could stream immidiately) if the typical user bandwidth was larger?
    - IshKebab 9y ago
      Yes. Although it still might not be as good due to TCP's slow start.
    - thefourthchime 9y ago
      In reality it's the size yes, but there is an inherent delay because of the way B-frames work. You'll need to buffer 2-3 frames worth 33ms each (for NTSC), so 66-99ms delay regardless of throughput. Audio doesn't have such a concept, you get 33ms worth of audio, you can play it right away. Of course, you can opt to not have b-frames and negate that issue.
      - mgamache 9y ago
        most (all?) of the video codecs designed for low latency don't use b-frames for this reason.
        thefourthchime 9y ago
        It's just a setting, all codecs can optionally not use b-frames.
  - jacquesm 9y ago
    > Audio is much easier to stream though. This isn't even remotely true. The brain will happily interpolate all kinds of visual information that is missing which allows you to drop frames with abandon as long as you display an older frame instead of a 'blank space'. Audio isn't nearly as forgiving and even a relatively modest jitter or number of lost packets will result in an un-intelligible stream of audio. I've spent many years of my life pumping video and audio across the net, even when that wasn't yet considered normal (or even an intended purpose of the net), and I've rarely heard complaints about video quality. But audio delivery requires top notch connectivity, low latency and sufficient throughput if you intend to hold a conversation with someone that does not result in irritation. Video is far more forgiving.
thefourthchime 9y ago
Please help me understand then. I see RLNC compared to 2022 Single mode has the same overhead of 25%. When I compare the two using your tool at the end of the article, the only change I see is an improvement from 5% random loss to 25%. The burst loose stays the same. Correct?
- mortenvp 9y ago
  Yes, you get a much better random loss protection with RLNC. So if you know that all your losses are bursts you may be able to live with 2022. Essentially the difference between the two algorithms are that with 2022 only a subset of your packets are protected by a redundancy packet (and you have to choose how to protect them), whereas with RLNC you can protect all available packets. If we leave the premise of this post (namely that we want to generate traffic in the same pattern as 2022) RLNC can even protect against longer bursts compared to 2022. Did that make sense?