Subject: [icnrg] low-latency and scalable video distribution

From: Dirk Kutscher <[email-masked]>
Date: Wed, 23 Mar 2022 11:19:48 +0100

Hello,

in case you missed it, the MOQ (Media over QUIC, https://datatracker.ietf.org/meeting/113/materials/agenda-113-moq-06) BOF at IETF-113 is discussing low-latency video distribution use cases.

The idea is to reduce latency for live streaming, i.e., achieving interactive conferencing latency without losing scalability.

The current thinking is using either RUSH (https://datatracker.ietf.org/doc/html/draft-kpugin-rush-00) or SRT over QUIC (meh ;-).

I believe that eventual solutions will have to do with stream prioritization, "relaxed" congestion control and incorporating the concept of relays.

Other topics/ideas that came up:

* application layer multicast
* local retransmissions
* content naming

Maybe something to look into from an ICN perspective...

Dirk

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 23 Mar 2022 11:21:18 +0100

Here is a comprehensive presentation that includes most of the aspects I mentioned:

https://datatracker.ietf.org/meeting/113/materials/slides-113-moq-5-range-of-architectures-00

Dirk

On 23 Mar 2022, at 11:19, Dirk Kutscher wrote:

> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 23 Mar 2022 06:44:07 -0400

Many use cases seem to suggest reasons to bring back coding in QUIC.

mjm

Marie-José Montpetit, Ph.D.
[email-masked]

From: Dirk Kutscher <[email-masked]> <[email-masked]>
Reply: Dirk Kutscher <[email-masked]> <[email-masked]>
Date: March 23, 2022 at 6:22:24 AM
To: ICNRG <[email-masked]> <[email-masked]>
Subject:  Re: [icnrg] low-latency and scalable video distribution

Here is a comprehensive presentation that includes most of the aspects I
mentioned:

Dirk

Hello,

in case you missed it, the MOQ (Media over QUIC,
https://datatracker.ietf.org/meeting/113/materials/agenda-113-moq-06) BOF
at IETF-113 is discussing low-latency video distribution use cases.

The idea is to reduce latency for live streaming, i.e., achieving
interactive conferencing latency without losing scalability.

The current thinking is using either RUSH (
https://datatracker.ietf.org/doc/html/draft-kpugin-rush-00) or SRT over
QUIC (meh ;-).

I believe that eventual solutions will have to do with stream
prioritization, "relaxed" congestion control and incorporating the concept
of relays.

   - application layer multicast
   - local retransmissions
   - content naming

Dirk
------------------------------

icnrg mailing list
[email-masked]

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 23 Mar 2022 11:55:16 +0100

I wouldn't start with the assumption that everything has to be based on a protocol with a connection-based security model.

Dirk

---

From: Luca Muscariello <[email-masked]>
Date: Wed, 23 Mar 2022 18:18:02 +0100

Hi Dirk

I was aware of these preliminary discussions but I'm still trying to
understand
the benefits of media over QUIC, beyond going through UDP port 443.
Even though network traversal for RTP has never been a major problem.
I would wait to see some data about the advantages as soon as they are
available.

I'm interested in the list of topics you have just made, which looks
very close to our own agenda: Scalability and infra offload via multicast
and
load balancing, reliability, content naming and security for real-time
applications.
In our team at Cisco this is an important use case.

One past reference here:

M. Papalini *et al*., "On the Scalability of WebRTC with
Information-Centric Networking," *2020 IEEE International Symposium on
Local and Metropolitan Area Networks (LANMAN*, 2020, pp. 1-6, doi:
10.1109/LANMAN49260.2020.9153228.

ICN looks like a perfect match for these applications.
@Marie-José we have now included coding by default in our hicn code base
and not only for real-time transport. It's definitely useful.

There is a big hicn code refactoring coming this week, or early next week
in case all tests take longer to pass, in the linux foundation repository,
with major emphasis on these use cases.
At least for those who are interested in the code base.

Luca

---

From: Dirk Kutscher <[email-masked]>
Date: Thu, 24 Mar 2022 09:08:31 +0100

Hi Luca,

> the benefits of media over QUIC, beyond going through UDP port 443.

Yes, exactly. IMO most of the arguments have to do with interests of existing stakeholders, existing code bases etc.

But it should be mentioned that the aspired benefits from using some form of multicast cannot be achieved in connection-based streaming – unless you are not actually using QUIC...

Or, unless you are creating an overlay QUIC relay network – not sure that's going to help with the low-latency...

> 10.1109/LANMAN49260.2020.9153228.

Thanks – yes, I'm aware of that paper – good work.

> ICN looks like a perfect match for these applications.

Yes, I think many people would agree. For new-generation distribution (and possibly ingestion), IMO there is real value in having a unified system and protocol architecture for both unicast and multicast, and for both VoD and live streaming.

However, I think it would be good to demonstrate experience with these large-scale low-latency scenarios more.

> At least for those who are interested in the code base.

Great – looking forward to it. Please announce it on this list.

Thanks,
Dirk

---

From: Jens Finkhaeuser <[email-masked]>
Date: Thu, 24 Mar 2022 09:09:40 +0000

Hi all,

quick background: my team and I wrote p2p video streaming protocols back in the day for Joost (2006 on-demand, 2008 live, give or take). A couple of years ago I realized that similar efforts tended to yield worse results (not in every aspect, this is very much a summary), and I sought funding for developing something new along those lines again. I received a grant, covid messed with my timing, and now I'm still in the earlier stages of it.

The TL;DR is, I would very much like to contribute solutions to this problem. It's just a tad too early for a draft yet. Maybe I can get something together before the autumn conference.

Happy to discuss here (or elsewhere)!

Jens

------- Original Message -------

> > M. Papalini et al., "On the Scalability of WebRTC with
> > 

> > Information-Centric Networking," 2020 IEEE International Symposium on
> > 

> > Local and Metropolitan Area Networks (LANMAN, 2020, pp. 1-6, doi:
> > 

> > On Wed, Mar 23, 2022 at 11:20 AM Dirk Kutscher [email-masked] wrote:
> > 

> > https://www.irtf.org/mailman/listinfo/icnrg_______________________________________________
>

---

From: Dirk Kutscher <[email-masked]>
Date: Thu, 24 Mar 2022 12:25:15 +0100

Hi Jens,

> Happy to discuss here (or elsewhere)!

That's great – thanks for reaching out.

Happy to discuss these ideas further – either online or offline.

JFYI, ICNRG has a meeting on Friday (slightly different topics on the agenda, but might still be of interest).

Best regards,
Dirk

---

From: Jens Finkhaeuser <[email-masked]>
Date: Fri, 25 Mar 2022 11:01:13 +0000

Hi,

unfortunately, this was my first IETF conference, and I could only book time for a single day. I suspect now that I understand the format better, I could make more time for the London one. So for the time being, it'll have to be on-list.

The protocol I'm developing has some overlap with QUIC, but is fundamentally different in other aspects. You could call it a parallel development; some basics of it go back to experiences with Joost, while I added other things later.

I suppose there are a number of relatively fundamental realizations that are not well reflected in protocols I've dived into so far (I may well be missing some!). Here's a quick overview:

1. In video, latency matters more than throughput. Users will accept a low frame rate more readily than stutters.
2. Related to this, as bandwidth availability reduces, reducing frame rate is a better mitigation than anything that can be done on the network layer. Some codecs permit on-the-fly reduction of frame rates, so some interactivity between the network and codecs could significantly improve perceived performance.
3. This means that TCP's resend behaviour or similar attempts at recreating this in QUIC are not actually very useful for the use-case.
4. On other hand, using FEC to increase the ratio of packets sent to frames delivered is a valid mitigation against packet loss as long as that throughput increase does not impact latency too much.
4a. It's pretty important to note here that "frames" as a distinct sequence of Bytes is not so much something that codecs produce; however, a reduced frame rate does result in reduced data if properly supported by the codec.
5. One benefit of using FEC is that it's also possible (within limits of the recipient's link overall bandwidth) to receive every Nth packet from a different source. The imbalance between consumer internet connections' ingress and egress bandwidths actively favours such an approach (there are architectural implications here too long to discuss in brief).
5a. Using consumer lines is perhaps a rather P2P consideration, but it does apply well to video conferencing. Not all use cases will benefit equally from this multi-sourcing, but for some it can be significant.
5b. Multi-sourcing is particularly interesting for local distribution. The use case we tended to use was football games that "everybody" watches. It is not necessary for a single stream into a local network to be relayed multiple times through a limited internet uplink if end nodes receive the majority of packets from peers.
5c. Multi-sourcing again introduces a few interesting architectural considerations relating to roles nodes take on in the distribution mesh. There is some overlap here with the CAN BoF I attended on Tuesday in that there is need for a "best node(s) for the job" kind of selection that might well become a routing rather than application layer question.
5d. Multi-sourcing needs to add/remove sources quite quickly. It's then important to establish connections with new sources with as few round trips as safe.
6. Fragmentation can kill latency, it's better to avoid it with a very conservative take on MTU.
7. All of the above make a UDP-based approach the most viable.
8. UDP traffic shaping is (was, I suppose I should say here!) in the form of strict rate-limiting per time unit, at the expiry of which packets get lost. Determining this path rate limit and reporting it to the codec is a crucial aspect in managing user experience.

(There are probably things I'm missing here, and I've left out a bunch of details.)

The protocol I'm working on is similar to QUIC in that it's UDP based. It also permits for multiple channels per "connection".

I have plans for adding FEC support, and a spin bit for RTT evaluation in the coming months. I also am beginning with implementing plans for working encryption into it; the current ideas are more based on WireGuard/NOISE than DTLS largely because the DTLS handshake is a little heavy for multi-sourcing cases in which a peer key is already known, but the connection dropped for some time.

Where it differs from QUIC, other than the above, is that there is no concession whatsoever to HTTP semantics. I've also worked hard to make channels even less interconnected than in QUIC, also with regards to the planned encryption layer (DTLS sequencing would, by my reading, produce problems for all QUIC channels on packet loss).

Finally, it doesn't really have TCP-like resend behaviour. Instead, I realized at some point that this stream orientation by contrast to UDP's datagram orientation is a product of three largely orthogonal characteristics, namely whether resends should happen, if packets are expected to be consumed in-order, and what close-on-loss behaviour exists (some of this comes from SCTP specs). I've made these individually selectable per-channel characteristics to permit modes better suited to streaming, while retaining the ability to map stream oriented behaviour onto the connection.

This transport I'm developing under a NGI grant (EU's next generation internet initiative) and I'm in parallel working on higher level components that should utilize this under an ISOC foundation grant. Either or both should eventually make it into a draft, but there is a long road ahead for both. However, while the scope is a bit wider than just video distribution, the latter was the experience on which I'm building, the impetus for starting this work, and a major use-case I'm considering in both parts of it. So if there is interest in this group in video distribution, I can prioritize the draft writing a bit.

Sorry, that was a bit of a brain dump. Best I can do on short notice. I'm looking forward to reading all the comments you might have at this very early point!

Jens

------- Original Message -------

> > On Thursday, March 24th, 2022 at 09:08, Dirk Kutscher [email-masked] wrote:
> >