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

[Jens Finkhaeuser <[e-mail]>]

Hi,
thanks, I'll review that as well!

Jens


------- Original Message -------
On Saturday, April 2nd, 2022 at 17:25, Dirk Kutscher <[e-mail]> wrote:


> Hi Jens,
> 

> thanks for the overview.
> 

> Regarding the MOQ discussion, I agree that a QUIC-based pub-sub protocol between relays for setting up application layer multicast distribution trees is not a good solution (I am sure it can be built, and given sufficient thrust, it can be made to work), but we have better technology for that.
> 

> There are quite many papers and implementations for ICN-based video distribution around that would provide:
> 

> -   object-based communication and security;
> -   implicit and opportunistic in-network caching;
> -   implicit efficient multipoint distribution;
> -   unified model for unicast and multicast;
> -   multi-sourcing (content-based...); and
> -   good interworking potential with network coding and in-network processing.
> 

> I am sure, others can provide additional pointers, but here is just one paper to start with:
> 

> https://ieeexplore.ieee.org/document/9579449
> 

> Happy to discuss this more.
> 

> Best regards,
> Dirk
> 

> On 25 Mar 2022, at 12:01, Jens Finkhaeuser wrote:
> 

> > 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 12:25, Dirk Kutscher <[e-mail]> wrote:
> > 

> > > Hi Jens,
> > 

> > > > 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)!
> > 

> > > 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
> > 

> > > > Jens
> > 

> > > > ------- Original Message -------
> > 

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

> > > > > Hi Luca,
> > 

> > > > > > 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.
> > 

> > > > > 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...
> > 

> > > > > > 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.
> > 

> > > > > 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.
> > 

> > > > > > 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.
> > 

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

> > > > > Thanks,
> > 

> > > > > Dirk
> > 

> > > > > > Luca
> > 

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

> > > > > > > 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
> > 

> > > > > > > _______________________________________________
> > 

> > > > > > > icnrg mailing list
> > 

> > > > > > > [e-mail]
> > 

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

> > > > > > _______________________________________________
> > 

> > > > > > icnrg mailing list
> > 

> > > > > > [e-mail]
> > 

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

> > > > > icnrg mailing list
> > 

> > > > > [e-mail]
> > 

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

> > > > > icnrg mailing list
> > 

> > > > > [e-mail]
> > 

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

> > > icnrg mailing list
> > 

> > > [e-mail]
> > 

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

> > icnrg mailing list
> > [e-mail]
> 

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