Subject: Re: [Moq] Two questions about how to move MOQ forward

From: Ian Swett <[email-masked]>
Date: Mon, 1 Nov 2021 10:17:20 -0400

On Sun, Oct 31, 2021 at 9:21 AM Ali C. Begen <ali.begen=
[email-masked]> wrote:

>
>
> > On Oct 31, 2021, at 2:09 PM, Ian Swett <ianswett=
> [email-masked]> wrote:
> >
> > However, there are use cases where DASH is used today, such as for
> lower-latency live streaming, where it creates some challenges and
> overhead.  It works, but using HTTP is hurting more than it's helping.
>
> Just to make sure we are on the same page, what challenges do you think
> DASH has for low-latency live streaming? Or what overhead does HTTP create
> in that case? For low-latency HLS, there are several server/CDN related
> issues people have reported already and despite the LL-HLS improvements,
> some issue still exist. I agree with that but I don’t see the same issues
> applying to DASH’s low latency.

The one I had in mind is that a client needs to have a large number of
requests outstanding if one wants to make requests not HOL blocking on one
another(ie: to allow dropping frames).  This can be a bit awkward(ie: maybe
you'd like to do a range request, but can't because you don't know the
right range) and as you approach single frame granularity, the overhead of
HTTP becomes substantial.   Additionally, you come close to hitting common
stream limits(ie: 100).

One can work around these issues, but it's more working around HTTP than
using it's featureset.

Ian

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 1 Nov 2021 14:26:17 +0000

+1

What we are talking about is a binding to QUIC that needs to describe how
an application uses transport services such as data sending, loss
detection, and recovery.

As Christian points out, we already have QUIC stacks that will allow an
application to select the congestion control algorithm. There's no
"protocol on the wire needed" to support this. But nor is there anything
that says what applications benefit from what types of algorithm.

One path forward is to include, in some document, guidance on how QUIC
implementations might present an API to manage connection-wide congestion
control for application such as RTP.

An alternative is the define new data-bearing QUIC frame types that do not
count towards bytes-in-flight counts. Then applications that need such
things make more explicit contracts, or fail to agree on the preconditions
needed to do so.

Cheers
Lucas

---

From: Ian Swett <[email-masked]>
Date: Mon, 1 Nov 2021 10:29:02 -0400

> control for application such as RTP.

I'd support this.

> things make more explicit contracts, or fail to agree on the preconditions

This seems potentially unsafe, at least for the public internet, so I would
oppose this unless there's a way to do this safely.

>
> Cheers
> Lucas
> --
> Moq mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/moq
>

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 1 Nov 2021 14:43:33 +0000

On Mon, Nov 1, 2021 at 2:29 PM Ian Swett <[email-masked]> wrote:

> This seems potentially unsafe, at least for the public internet, so I
> would oppose this unless there's a way to do this safely.
>

Good point but can you explain how this is any more unsafe than allowing
implementations QUIC to be configured to disable CC on a connection?

To explain what I meant in the proposal, let's imagine a new STREAM_NO_CC
frame. Support for receiving such a frame could be indicated in a Transport
parameter. Use of the frame would be restricted (as far as we can with a
MUST/MUST NOT) to application protocol mappings that would describe how
such frames are used and how the congestion control is provided by the
application protocol. I don't claim that this is a fully realised solution,
identifying realy issues to not doing this would be helpful.

Cheers,
Lucas

---

From: Ian Swett <[email-masked]>
Date: Mon, 1 Nov 2021 10:55:23 -0400

On Mon, Nov 1, 2021 at 10:43 AM Lucas Pardue <[email-masked]>
wrote:

>> An alternative is the define new data-bearing QUIC frame types that do
>>> not count towards bytes-in-flight counts. Then applications that need such

It's equally unsafe, but a bit less ugly.  I don't think disabling
congestion control completely is the right option either, but = possibly we
could allow disabling it and pick some congestion targets above which a
congestion controller kicks in.  If the app's congestion controller is
doing the right thing, then it gets to run it's own congestion controller
and if it behaves poorly, it doesn't.  This is a bit like the L4S approach.

The BBR team derived a set of constants for BBR2 to make it 'fair' with
Reno/Cubic, so we could start with those as thresholds.  We could also
consider imposing a form of packet conservation, but we'd have to be
careful to get that right, as the standard TCP definition could be very
harmful to realtime apps, as well as too conservative.

I'm not in love with magic thresholds or packet conservation, but they seem
better than running without a congestion controller.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 1 Nov 2021 16:58:28 +0200

Hi,

On 2021-11-1, at 16:55, Ian Swett <ianswett=[email-masked]> wrote:
> I don't think disabling congestion control completely is the right option either, but = possibly we could allow disabling it and pick some congestion targets above which a congestion controller kicks in.  If the app's congestion controller is doing the right thing, then it gets to run it's own congestion controller and if it behaves poorly, it doesn't.

this sounds a lot like circuit breakers, aka https://datatracker.ietf.org/doc/html/rfc8084

Thanks,
Lars

---

From: Ian Swett <[email-masked]>
Date: Mon, 1 Nov 2021 11:15:46 -0400

Thanks Lars, that looks like the right concept, though I believe there
would need to be a bit of work to map it into a protocol like QUIC, where
ACKs are providing the key pieces of feedback?

On Mon, Nov 1, 2021 at 10:59 AM Lars Eggert <[email-masked]> wrote:

> > I don't think disabling congestion control completely is the right
> option either, but = possibly we could allow disabling it and pick some
> congestion targets above which a congestion controller kicks in.  If the
> app's congestion controller is doing the right thing, then it gets to run
> it's own congestion controller and if it behaves poorly, it doesn't.
>
> this sounds a lot like circuit breakers, aka
> https://datatracker.ietf.org/doc/html/rfc8084
>
> Thanks,
> Lars
>
>

---

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Mon, 1 Nov 2021 09:02:02 -0700

Speaking as an individual.

I strongly disagree with the idea of disabling transport congestion control
for media streaming.  I can see the appeal, akin to a "one chef in the
kitchen" analogy, but I think it is a false simplification in this domain
for a few reasons.

Well implemented congestion control is supposed to automatically stay out
of the way for rate-limited applications.   It depends on the timescale you
observe from, but I argue that ABR media streams are fundamentally closer
in nature to rate-limited than bulk-transport/elastic.  This is mainly
because completely elastic media translates to a bad user
experience---drastic and frequent quality changes that would result from
tracking network dynamics too closely will become perceptibly annoying.

Many (most?) QUIC implementations are user-level.  In some sense, this
means tight co-operation between "transport" and "ABR" is likely more
attainable than back in the day when user-kernel boundaries were more in
the middle of things.  Not a new idea, the Salsify research is one good
example that comes to mind.

In my mind, if you try to take the short-cut of dropping transport CC and
just doing it in the media layer, you will re-invent the wheel there, but
probably in a inferior way.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 1 Nov 2021 11:32:24 -0500

OK, so, I blinked, and we now have a conversation going. Let me try to
catch up (at least a little). And no one

It looks like we have some things to talk about in at least one side
meeting.

Lucas asked if there are IETF sessions that are related (in some way) to
the topics in the drafts that James and I announced on this mailing list,
that would affect scheduling. I see one - At least AVTCORE, on Friday, has
one  relevant 15-minute presentation, as

4. RTP over QUIC (J. Ott, M. Engelbart, 15 min)
https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic
https://www.in.tum.de/fileadmin/w00bws/cm/papers/epiq21-rtp-over-quic.pdf

Having said that, IETF 111 attendee practice at
https://trac.ietf.org/trac/ietf/meeting/wiki/111sidemeetings seems to have
been to avoid IETF meeting slots, just so we didn't have to watch conflicts
as closely, and I had assumed that we could do the same for IETF 112, at
least for these meetings. That would give us an 18:15 UTC start time,
assuming that we met after the final session most days. Would anyone object
to that? (I know that the ART ADs have announced office hours at 18:15 on
Monday, so as long as they're involved, perhaps best to avoid that
conflict). Details are at
https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings.

Lucas asked if folks aligned on a single problem, or aligned on
differentiable problems? I.e. is there one or many problems to solve. I
think that further discussion in this thread has proved, without question,
that we're not aligned on a single problem. I don't think we have MANY
problems to solve (and I mean that at the use case level), but I do think
we have a few problems to solve.

What I'd like to do, at the first meeting, is to try to figure use cases
and requirements out. And further discussion on this list (before IETF 112)
would be helpful - let me start another thread for that.

Lucas asked if the different proposals are answers to specific problems.
I'd say "probably", but I think we have a use case/requirements
conversation due first, because knowing what OTHER problems the proposals
might, or might not, solve, would be super helpful, before we all head off
in different directions.

Lucas asked whether the different proposals needed to be pursued in the
IETF. And if so, in what classification. I think we're miles away from
knowing about classifications, but at a minimum, the RTP-related proposals
are squarely within the IETF's scope, and since I'd like to focus on use
cases and requirements before we focus on solution proposals, Perhaps, late
in the week, it will be useful to have a second meeting to figure out what
work would be pointed where (existing WG with existing charter, existing WG
with updated charter, new WG charter proposal, BOF proposal).

Are there people who think two meetings, both at 18:15 UTC start time, with
these topics, is a BAD idea? Specifically,
TUESDAY 9 NOVEMBER
<https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings#point2>
<https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings#TUESDAY9NOVEMBER>
*Time* *Duration* *Time Zone* *Area* *Meeting Name* *Contact* *Meeting
Description* *Conferencing Link* *.ics*
18:15 90 min UTC MOQ Use Cases and Requirements |x|
FRIDAY 13 NOVEMBER
<https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings#point2>
<https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings#TUESDAY9NOVEMBER>
*Time* *Duration* *Time Zone* *Area* *Meeting Name* *Contact* *Meeting
Description* *Conferencing Link* *.ics*
18:15 60 min UTC MOQ Next Steps |x|
If so, please advise!

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 1 Nov 2021 12:57:26 -0500

I'm probably not going to engage further in this (important) thread, just
because it's a busy week before a busy week, but

   - Christian's right, we chartered QUIC to use NewReno (as in
   https://www.rfc-editor.org/rfc/rfc9002.html), but decisions about other
   congestion control mechanisms are kind of up to the sender, as described in
   https://www.rfc-editor.org/rfc/rfc9002.html#name-congestion-control,
   - We've had some especially bloody conversations about what to do when
   "something" (often network monitoring systems) notices that a sender is
   causing problems and isn't responsive to those problems, resulting in
   "circuit breakers", as described in
   https://datatracker.ietf.org/doc/html/rfc8084 (for network transport in
   general - it's usually referenced by tunneling protocols like
   https://www.rfc-editor.org/rfc/rfc7510.html#section-5) and
   https://datatracker.ietf.org/doc/html/rfc8083 f(or RTP),
   - The best guidance we've been able to provide for UDP-based
   applications, which still applies to QUIC, is
   https://www.rfc-editor.org/info/rfc8085, and
   - At no point during six years as a TSV AD did I think we had a GREAT
   plan for runaway senders on the Internet, as opposed to having a great plan
   for senders using protocols published in the IETF stream.

Is the topic of what to do about runaway senders, especially on unmanaged
paths, still ICCRG territory?

Best,

Spencer

On Mon, Nov 1, 2021 at 11:02 AM Charles 'Buck' Krasic <
[email-masked]> wrote:

> I strongly disagree with the idea of disabling transport congestion
> control for media streaming.  I can see the appeal, akin to a "one chef in
> the kitchen" analogy, but I think it is a false simplification in this
> domain for a few reasons.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 1 Nov 2021 13:39:09 -0500

Just following up on this - I added roughly these two meetings in the Side
Meetings wiki, at
https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings.

I can provide conferencing information for these (just not right now),
using Zoom with up to 100 people, I believe.

If anyone else wants to (1) help organize these meetings, or (2) replace me
as the contact and be more awesome than I would be, that's fine, too. I'm
just trying to get on everyone's schedule!

Best,

Spencer

On Mon, Nov 1, 2021 at 11:33 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> https://trac.ietf.org/trac/ietf/meeting/wiki/111sidemeetings seems to
> have been to avoid IETF meeting slots, just so we didn't have to watch
> conflicts as closely, and I had assumed that we could do the same for IETF
> 112, at least for these meetings. That would give us an 18:15 UTC start
> time, assuming that we met after the final session most days. Would anyone
> object to that? (I know that the ART ADs have announced office hours at
> 18:15 on Monday, so as long as they're involved, perhaps best to avoid that
> Are there people who think two meetings, both at 18:15 UTC start time,
> with these topics, is a BAD idea? Specifically,
> TUESDAY 9 NOVEMBER

---

From: "Ali C. Begen" <[email-masked]>
Date: Mon, 1 Nov 2021 22:45:57 +0300

> HTTP becomes substantial.   Additionally, you come close to hitting common

Neither DASH nor HLS operates that way, i.e., at the media frame level.
Both use addressable media objects.In theory, you can indeed create
single-frame chunks for reducing the latency, but even in that case LL-DASH
still uses a single request per segment (which is several seconds long)
[This is where LL-HLS differs and it may use multiple requests per chunk
(aka part). So, the use of HTTP (or any other request-response protocol) is
still OK.

What you are alluding to is quite different from the DASH/HLS model.

-acbegen

---

From: "Ali C. Begen" <[email-masked]>
Date: Mon, 1 Nov 2021 23:07:31 +0300

10 years ago we showed and then proved that most annoying problems in ABR
were due to the fact that we had two chefs in the kitchen. TCP was
responsible for running the congestion/rate control and actual transport
but then based on the TCP's delivery and other app-layer signals that were
not visible to TCP (like the playback buffer goes empty when the user
seeks), the app-layer logic (ABR logic aka rate adaptation) would decide on
what bitrate/resolution should be asked from the server. We called these
outer and inner control loops. When you have two such controllers in a
system, you can easily create negative feedback and that is a bad thing. It
is the reason ABR clients keep oscillating and/or do not share the
resources (available bw) in a fair manner and/or the overall network
utilization suffers.

Is this because the CC in TCP is not well implemented? Not at all. It is
because you cannot put two guys in charge of a company. There must be a
single boss. And the app-layer is the natural choice in this case.

I am not arguing to totally disable the rate control at the transport
layer, one can put a breaker or two there as well but to me the app-layer
rate control in the case of ABR works just fine.

-acbegen

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 1 Nov 2021 15:09:19 -0500

Dear MOQ fans,

Mo pointed out that I had the date for Friday as the 13th in my email -
it's actually the 12th, and that's correct in the Side Meeting wiki, which
is what matters now.

Thanks for keeping an eye on me, Mo!

Best,

Spencer

On Mon, Nov 1, 2021 at 1:39 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> If anyone else wants to (1) help organize these meetings, or (2) replace
> me as the contact and be more awesome than I would be, that's fine, too.
> I'm just trying to get on everyone's schedule!
>
> Best,
>
> Spencer
>

---

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Mon, 1 Nov 2021 13:21:24 -0700

On Mon, Nov 1, 2021 at 1:07 PM Ali C. Begen <[email-masked]>
wrote:

...snip...

>  Not at all. It is because you cannot put two guys in charge of a company.
> There must be a single boss.
>
..snip..

> -acbegen

We think differently where I work, and happen to have two co-CEOs.  Sorry,
I could not resist.  :P

---

From: Luke Curley <[email-masked]>
Date: Mon, 1 Nov 2021 13:21:53 -0700

Hey folks, thanks for kicking off this mailing list!

I've been heading the project to reduce video latency at Twitch. We've been
using LHLS (custom chunked-transfer variant), tried and failed to use
WebRTC, and are now in the process of rolling out a new QUIC-based
solution. I recently gave a Demuxed presentation on our approach (including
a plug for MOQ), although I don't think there's a VOD yet. I'll start a new
thread for the specific problems we've run into at Twitch.

There are many different media use-cases, and an equally large number of
video protocols to handle those use-cases. It can be boiled down to an
unavoidable trade-off between quality and latency. Protocols like WebRTC
and HLS/DASH lack the flexibility to target both ends of the latency
spectrum, but I definitely think it's possible to design a video protocol
that can.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 1 Nov 2021 19:03:50 -0500

Hi, Luke,

On Mon, Nov 1, 2021 at 3:22 PM Luke Curley <[email-masked]> wrote:

> I've been heading the project to reduce video latency at Twitch. We've
> been using LHLS (custom chunked-transfer variant), tried and failed to use

Thank you for jumping in! That seems very helpful.

I look forward to your new thread!

Best,

Spencer

---

From: Luke Curley <[email-masked]>
Date: Mon, 1 Nov 2021 19:20:39 -0700

There MUST be some form of congestion and flow control. Disabling
congestion control in QUIC because you trust the application to handle it
just sounds like a mistake (ex. QUIC datagrams). If QUIC has inadequate
congestion control then I say improve it, not disable it. For example, the RTP
transport wide CC extension
<https://datatracker.ietf.org/doc/html/draft-holmer-rmcat-transport-wide-cc-extensions-01>
carries
the arrival time for every packet, which is probably also useful for QUIC
congestion control. RTP has been optimized for minimal queuing and
application-limited flows, while TCP has been optimized for high bandwidth
and full pipes, but they can certainly use the same primitives.

The one thing that live video needs the most is an accurate bitrate
estimation. If QUIC's congestion control can spit out a good bitrate for
the encoder, then QUIC works pretty well for live video. I've implemented
Reno, CUBIC, and BBR at this point, but they all have issues providing an
accurate bitrate estimation. I think it's just a case of these algorithms
being designed to maximize overall throughput rather than minimize queuing.

---

From: Luke Curley <[email-masked]>
Date: Mon, 1 Nov 2021 19:28:18 -0700

(I hit the send button too soon)

For example, BBR occasionally enters PROBE_RTT mode where it basically
stops sending traffic for a short period so it can reaffirm the minimum
RTT. This might increase the overall throughput but this sudden stall
causes the live video stream to buffer. Even just today I realized that the
bitrate estimator returns the rate at which packets should be sent, but
this is not the same as the rate at which packets arrive during packet
loss, so it can't be fed directly to the encoder.

On Mon, Nov 1, 2021 at 7:20 PM Luke Curley <[email-masked]> wrote:

> <https://datatracker.ietf.org/doc/html/draft-holmer-rmcat-transport-wide-cc-extensions-01> carries

---

From: Ian Swett <[email-masked]>
Date: Tue, 2 Nov 2021 05:57:15 -0400

Yes, PROBE_RTT is a real challenge for using BBR in realtime apps.  BBRv2
uses a shallower(50%) PROBE_RTT, but it's still a huge drop in throughput.

For per-packet timestamps, Connor Smith and I wrote up a potential design
that adds them to QUIC:
https://datatracker.ietf.org/doc/draft-smith-quic-receive-ts/. This was
motivated by GoogCC and other congestion controllers that use per-packet
timestamps today.  Thoughts appreciated as to whether this is helpful for
your use cases.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 2 Nov 2021 09:45:58 -0500

Dear MOQ fans,

I'm going to update the side meeting entries for "MOQ Use Cases and
Requirements" (on Tuesday) and "MOQ Next Steps" in
https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings, to add Video
Conferencing links and ICS files.

I'll add descriptions, but please note that I'm very interested in input
about what we're actually doing in both meetings, so I'm fine with updating
the descriptions to match what we actually need to talk about.

Best,

Spencer

---

From: "Ali C. Begen" <[email-masked]>
Date: Tue, 2 Nov 2021 23:25:21 +0300

> On Nov 2, 2021, at 5:28 AM, Luke Curley <[email-masked]> wrote:
> 
> For example, BBR occasionally enters PROBE_RTT mode where it basically stops sending traffic for a short period so it can reaffirm the minimum RTT. This might increase the overall throughput but this sudden stall causes the live video stream to buffer. Even just today I realized that the bitrate estimator returns the rate at which packets should be sent, but this is not the same as the rate at which packets arrive during packet loss, so it can't be fed directly to the encoder.

I suppose you are referring to the upload/contribution/ingest as you would not adjust your encoder’s output on the distribution side (each client will have a different available bw).

> There MUST be some form of congestion and flow control. Disabling congestion control in QUIC because you trust the application to handle it just sounds like a mistake (ex. QUIC datagrams). If QUIC has inadequate congestion control then I say improve it, not disable it.

I am not arguing that QUIC’s CC (whatever has been implemented to date) is inadequate. I am only stating that it messes with what the ABR layer does. If you are still considering the ingest side, then my comment does not apply.

> For example, the RTP transport wide CC extension carries the arrival time for every packet, which is probably also useful for QUIC congestion control. RTP has been optimized for minimal queuing and application-limited flows, while TCP has been optimized for high bandwidth and full pipes, but they can certainly use the same primitives.
> 
> The one thing that live video needs the most is an accurate bitrate estimation. If QUIC's congestion control can spit out a good bitrate for the encoder, then QUIC works pretty well for live video. I've implemented Reno, CUBIC, and BBR at this point, but they all have issues providing an accurate bitrate estimation. I think it's just a case of these algorithms being designed to maximize overall throughput rather than minimize queuing.

Which time scale is being used for measuring the available bandwidth is important. What is the scale you are looking at (I am still assuming this is on the ingest side)?

---

From: Luke Curley <[email-masked]>
Date: Wed, 3 Nov 2021 13:50:39 -0700

I'm using the estimated bitrate as reported by the congestion control
algorithm and rounding down to the nearest rendition. This is only as
accurate as the bitrate estimator in the congestion control algorithm.
However it avoids split brain, where the player thinks it can support one
rate while the congestion control algorithm can actually send at a
different rate entirely.

On Wed, Nov 3, 2021 at 1:38 AM Ali C. Begen <[email-masked]>
wrote:

> I suppose you are referring to the upload/contribution/ingest as you would
> not adjust your encoder’s output on the distribution side (each client will
> have a different available bw).
>
> congestion control then I say improve it, not disable it.
>
> I am not arguing that QUIC’s CC (whatever has been implemented to date) is
> inadequate. I am only stating that it messes with what the ABR layer does.
> If you are still considering the ingest side, then my comment does not
> apply.
>
> > For example, the RTP transport wide CC extension carries the arrival
> time for every packet, which is probably also useful for QUIC congestion
> control. RTP has been optimized for minimal queuing and application-limited
> flows, while TCP has been optimized for high bandwidth and full pipes, but
> they can certainly use the same primitives.
> >
> Which time scale is being used for measuring the available bandwidth is
> important. What is the scale you are looking at (I am still assuming this
> is on the ingest side)?
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 3 Nov 2021 14:10:09 -0700

> rate while the congestion control algorithm can actually send at a

That. Plus also the advantage of seeing more packets than just the media 
stream. The QUIC connection might also carry background traffic such as 
document transfers, or maybe probing traffic. The QUIC-level bandwidth 
estimator sees all of that, an app specific estimator does not.

That does not mean that every QUIC-level congestion control algorithm 
would work well for MoQ. I would certainly not use Reno or Cubic, for 
example. BBR might work, if we find a way around the "Probe RTT" issue 
that causes a stall every 10 seconds.

Of course, the probe-RTT feature is there for a reason. Congestion 
control algorithms that try to minimize delay end up building a 
dependency on the estimate on min RTT on the path. There are known 
issues with that. Established connections slow down if they see the RTT 
climbing higher than the target minimum, but new connections only 
observe the "most recent" min, and that gives an advantage to newcomers. 
Shortening the window on which the min is computed equalize the effect 
among competing connection, but then the RTT drifts higher for 
everybody. The "probe RTT" is designed to slow transmission enough so 
that queues get empty, and everybody competing connection can get a 
"clean" sample of min RTT. That has unfortunate effect for continuous 
streaming, so we need to design an alternative. But designing that is 
hard...

-- Christian Huitema

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Nov 2021 15:33:59 -0700

On Nov 3, 2021, at 13:51, Luke Curley <[email-masked]> wrote:
> 
> 
> I'm using the estimated bitrate as reported by the congestion control algorithm and rounding down to the nearest rendition. This is only as accurate as the bitrate estimator in the congestion control algorithm. However it avoids split brain, where the player thinks it can support one rate while the congestion control algorithm can actually send at a different rate entirely.

[BA] The concept of “encoder average bitrate” is one of the problems here.  The idea that the bandwidth consumed by a key frame and subsequent delta frames will somehow “average out” doesn’t make much sense, particularly if we are talking about simulcast or SVC modes where you can have bandwidth spikes in multiple layers within the same time unit. 

In practice, what we see is that the “average bitrate” consists of an overshoot around the keyframe(s) followed by an undershoot in the subsequent delta frames.  If the overshoot results in loss, the keyframe(s) need to be resent, and in that case the “average bitrate” isn’t of much help.  It’s like averaging a boulder and a pebble and concluding that the “average” will fit through the door just fine. 

It is more useful to think about the size of the next frame to be sent, and the network’s ability to accommodate that.  This is one of the key insights of Salsify. 

>> On Wed, Nov 3, 2021 at 1:38 AM Ali C. Begen <[email-masked]> wrote:
>> 
>>

---

From: "Ali C. Begen" <[email-masked]>
Date: Thu, 4 Nov 2021 10:37:07 +0300

OK, this is not the ingest side (it was a bit confusing because you kept
referring to the encoder output). Anyways, if the transport layer can tell
you what tput it can sustain at this time, naturally it will be more
accurate than trying to determine the available bw at the ABR layer. But
the timescale the transport layer is using is quite important. If it is
giving you a tput value every 100ms, it may be noisy and it won't help you
when you are using segments of several seconds. Just because tput dropped
momentarily does not mean you will stall, either.  You need to somehow
filter/smooth it out. If it is giving you info every second, then the value
you are getting from the transport layer won't be much different than what
you are measuring at the ABR layer. That is what I wanted to point out
(timescale wrt your decision frequency and horizon is the critical piece
here).

As you already know, actual segment encoding bitrates are likely to be
quite different from the advertised rendition bitrates. So, picking the
highest one below the reported bw does not necessarily work, either (this
is another problem but also a big reason why sometimes stalls do happen).

-acbegen

On Wed, Nov 3, 2021 at 11:50 PM Luke Curley <[email-masked]> wrote:

>> I suppose you are referring to the upload/contribution/ingest as you
>> would not adjust your encoder’s output on the distribution side (each
>> client will have a different available bw).
>>
>> I am not arguing that QUIC’s CC (whatever has been implemented to date)
>> is inadequate. I am only stating that it messes with what the ABR layer
>> does. If you are still considering the ingest side, then my comment does
>> not apply.
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 4 Nov 2021 08:24:17 -0500

Warning, you have entered the land of Spencer's Opinions and Questions ...

> is another problem but also a big reason why sometimes stalls do happen).

I THINK we're talking about what could be possible for streaming media (and
probably a few other flavors of media), if the transport layer and video
codec work together.

I saw Bernard's invocation of Salsify (a past ANRP winner in 2020, by the
way - I believe https://snr.stanford.edu/salsify/ is a reasonable
description, and the ANRP talk is at https://irtf.org/anrp/, under the
"past winners" tab). That's certainly one way of working together - tight
integration of the codec with the transport layer. But we have a richer
transport layer available than the Salsify people had in 2018. Maybe we
could do better now?

ISTM that continuing to talk about what is possible for video if it doesn't
have to guess what the transport layer under it is going to do, is an
incredibly valuable discussion to have. I have to ask, is this the right
place to have it?

"Yes" is a possible answer, and if so, we should probably mention this
discussion in places like QUIC and ICCRG, so that we're not having a
conversation here, that we'll have to repeat somewhere else with different
people.

 I'm not in any way the moderator for this mailing list, but I would like
to hear people's thoughts about that.

Best,

Spencer

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 4 Nov 2021 14:12:24 +0000

Hey Spencer,

On Thu, Nov 4, 2021 at 1:24 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> <snip>
> ISTM that continuing to talk about what is possible for video if it
> doesn't have to guess what the transport layer under it is going to do, is
> an incredibly valuable discussion to have. I have to ask, is this the right
> place to have it?
>

I agree.

Mentioning it in QUIC seems fine. While the charter states that "Defining
new congestion control schemes is explicitly out of scope", this thread of
discussion seems to be more about the glue between the QUIC transport and
other things. That might yield new ideas for information exchange between
application and transport, or even full-fledged extensions to the
transport. Those such things would in theory be in scope even if a CC algo
was pursued elsewhere.

Cheers
Lucas

---

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Thu, 4 Nov 2021 07:20:05 -0700

Food for thought. Aside from and complimentary to CC, I think scheduling is
interesting in this space. Is HTTP ideal? If so, does the latest work on
priorities suit the use cases? If not HTTP, what options for explicit
priorities and QUIC might there be?

---

From: "Piers O'Hanlon" <[email-masked]>
Date: Thu, 4 Nov 2021 14:50:33 +0000

On 4 Nov 2021, at 14:20, Charles 'Buck' Krasic <[email-masked]<mailto:[email-masked]>> wrote:

Food for thought. Aside from and complimentary to CC, I think scheduling is interesting in this space. Is HTTP ideal? If so, does the latest work on priorities suit the use cases? If not HTTP, what options for explicit priorities and QUIC might there be?

Priorities can help - especially if one wants to quickly deprioritize a stalled/slowed response, though this currently requires HTTP Frame based signalling support which isn’t currently directly controllable in the browser client side.

With respect to information exchange in the stack there’s also the aspect of who you want to share [network transport] information with and at what scale. Whilst Salsify (and their other ANRP@IETF110 talk - Learning in Situ) might be great for one-to-one/some communication where the sender has access to such network information, but with operations at scale where clients can’t currently access such information and you don’t want to resource an active [edge] node for each receiver, then the server may want to share information about the transport level to clients - this could also be handled at the HTTP level (e.g. my [expired] transport-info<https://datatracker.ietf.org/doc/draft-ohanlon-transport-info-header/> draft).

On Thu, Nov 4, 2021 at 7:12 AM Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
Hey Spencer,

On Thu, Nov 4, 2021 at 1:24 PM Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:
Warning, you have entered the land of Spencer's Opinions and Questions ...

<snip>

ISTM that continuing to talk about what is possible for video if it doesn't have to guess what the transport layer under it is going to do, is an incredibly valuable discussion to have. I have to ask, is this the right place to have it?

"Yes" is a possible answer, and if so, we should probably mention this discussion in places like QUIC and ICCRG, so that we're not having a conversation here, that we'll have to repeat somewhere else with different people.

I agree.

Mentioning it in QUIC seems fine. While the charter states that "Defining new congestion control schemes is explicitly out of scope", this thread of discussion seems to be more about the glue between the QUIC transport and other things. That might yield new ideas for information exchange between application and transport, or even full-fledged extensions to the transport. Those such things would in theory be in scope even if a CC algo was pursued elsewhere.

Cheers
Lucas

--
Moq mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/moq

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 4 Nov 2021 18:09:58 +0000

On 11/4/21, 9:25 AM, "Moq on behalf of Spencer Dawkins at IETF" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
...snip...
> ISTM that continuing to talk about what is possible for video if it doesn't have to guess what the transport layer under it is going to do, is an incredibly valuable discussion to have. I have to a…

RMCAT was supposed to solve this for RTP, and there was hope the solution(s) could be generally applicable to other media transports. However, I don’t think there is any consensus yet on the best solution(s) even for RTP, much less more generally. The only clear consensus was that delay-sensitive designs benefit from receive timestamps, so standardized feedback (RTCP in the case of RMCAT) allows different senders and receivers to interoperate regardless of the congestion control implementation or version. There is now a similar proposal for QUIC, as Ian mentioned, which is a good start.

While there is clearly interest on this list in QUIC CC specifically tuned for media, I suspect we will rehash a lot of stuff without the full context of prior explorations in RMCAT and QUIC (BBRv1/2). Maybe the discussion here can just pinpoint the current pain points, like probing behavior impacting throughput, CC “guidance” to media rate control [1], etc.

[1] RMCAT explored this in 2014: https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-app-interaction-01#section-5.4.1

Mo

---

From: Christian Huitema <[email-masked]>
Date: Thu, 4 Nov 2021 12:05:43 -0700

On 11/4/2021 6:24 AM, Spencer Dawkins at IETF wrote:

> way - I believehttps://snr.stanford.edu/salsify/  is a reasonable
> description, and the ANRP talk is athttps://irtf.org/anrp/, under the

The Salsify papers show the benefit of a tight feedback between the 
state of the transport protocol and the video codec. This requires APIs 
for exposing the transport protocol state to the application. It seems 
easier to deploy this kind of API with an application space transport 
like QUIC than with a kernel implementation of TCP.

-- Christian Huitema

---

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Thu, 4 Nov 2021 12:21:21 -0700

> like QUIC than with a kernel implementation of TCP.
Exposing the transport state is one part of tight integration.  I have long
felt priorities are an important ingredient to the app providing more
information to the transport. There have been a lot of mis-steps in the
past (e.g. HTTP/2 priorities), so if anything it would seem clear that a
good design is non-trivial.

One common past assumption in the space is that priorities are used by the
client to inform a server and the server is the primary enforcer, but this
is problematic because many non-trivial services and use-cases involve the
client(s) concurrently communicating with more than one distinct server
instance.   I think it's an interesting research topic to find some sort of
co-operative distributed priority scheme, perhaps moving primary scheduling
responsibility from servers to clients (akin to DASH and HLS decisions
being client driven), or some other more evolved notions of fairness.  GTA
(MMSY 2018) and Minerva (SIGCOMM 2019) spring to mind.

---

From: "Ali C. Begen" <[email-masked]>
Date: Fri, 5 Nov 2021 12:10:32 +0300

> On Nov 4, 2021, at 4:24 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> I THINK we're talking about what could be possible for streaming media (and probably a few other flavors of media), if the transport layer and video codec work together. 

There are at least three threads in the mailing list now and they are all mixed up with each other. More or less, everybody has the same goal: how can we achieve better cooperation between transport and and media application?

1) If you are doing a 1:1 type of session, the real-time codec can be influenced based on the info from the transport/RTP layer (like the work in RMCAT). Alternatively, the codec can do its own magic and then tell the transport to (de)prioritize some packets. Sky is the limit in this scenario, so many options. There are hundreds of papers on this. And doing some API work is probably the only thing we can do in the IETF.
2) If you are doing 1:many VoD streaming (dash/hls), codec side is already fixed, and you either do measurements in the app layer and can use http priority or alike to influence the transport. Or, the transport can tell you what it can do and the you rate-adapt in the app layer accordingly. Here, the cooperation is not as much useful due to the larger buffering on the client side, the app layer can most of the time do the right w/o the direct help from the transport (transient/fine-granular transport info is not that essential).
3) If you are doing 1:many live streaming, the observations in 2) still hold, but in this case, the cooperation becomes a bit more important as now the buffer is shorter and the app-layer may benefit from the detailed info coming from the transport layer. Still as you can imagine, we are not touching on the codec as it cannot be adjusted for each client. The codec does its own job in the best fashion hoping that the ingest side of the network can sustain the needed bitrate. If that part is problematic, then obviously the codec should adapt as quickly as possible based on the network conditions. So, for the ingest side, there is a benefit from transport/codec cooperation but this mostly applies to Twitch-like user generated content. For olympics or professional live video, the ingest would never have a bandwidth issue anyways.
4) If there are folks who would argue for user-specific live/vod streaming (as opposed to dash/hls that uses a set of pre-defined encodings for everybody) like RTSPv3, that is another approach. But, we need to be convinced whether that is a justified approach given the history of such approaches.

-acbegen

---

From: "Ali C. Begen" <[email-masked]>
Date: Fri, 5 Nov 2021 18:28:50 +0300

> On Nov 4, 2021, at 10:21 PM, Charles 'Buck' Krasic <[email-masked]> wrote:
> 
> 
> 
> On Thu, Nov 4, 2021 at 12:05 PM Christian Huitema <[email-masked]> wrote:
> Exposing the transport state is one part of tight integration.

Indeed.

> I have long felt priorities are an important ingredient to the app providing more information to the transport. There have been a lot of mis-steps in the past (e.g. HTTP/2 priorities), so if anything it would seem clear that a good design is non-trivial.  
> 
> One common past assumption in the space is that priorities are used by the client to inform a server and the server is the primary enforcer, but this is problematic because many non-trivial services and use-cases involve the client(s) concurrently communicating with more than one distinct server instance.

Right, and the problematic part of the network could be somewhere different, e.g., the access point or the access or aggregation link. Using a priority on the server will not help much.

>   I think it's an interesting research topic to find some sort of co-operative distributed priority scheme, perhaps moving primary scheduling responsibility from servers to clients (akin to DASH and HLS decisions being client driven),

And further the client being assisted/hinted by the server/network (and the servers being hinted by the clients). CMCD is done, CMSD is ongoing: https://www.linkedin.com/pulse/manus-manum-lavat-ali-c-begen/

> or some other more evolved notions of fairness.  GTA (MMSY 2018) and Minerva (SIGCOMM 2019) spring to mind.

I can speak for GTA. GTA performs pretty well and has all the nice features we need. The problem is that it works well only if the majority of the clients implement it. I suspect this will be the case for any client-driven solution. That means if there are some “bad” clients who want to cheat the system, it is relatively easy to do that and the “good” clients pay for it.

-acbegen