Scribe for morning is Mike.
Goals for the Interim
Agenda Bash
Interop Readout (10 min)
How Rough Consensus Works (10 min)
Cullen presenting Use Cases
First slide (Slide 2) biggest, with lots of stuff to cover
video older than 30 mins not allowed
* Mike: clarify distinction between cache hints vs.
contracts
* Will: caching question not applicable to prioritizing
what we deliver
* Cullen:
* Victor:
^
video that needs to be played soon is more important than
audio far in the future
* Alan: this competes with other requirements like 'audio
more important than video'
* Kiril: yes, audio and video may be equally important
within some time window
* Jana: time limits more important than anything else,
then other relative priorities
* Cullen: many solutions, yes, like some offsetting in the
original WARP draft
^
WiFi should order with priority AC_VO (voice) or AC_VI
(video interactive)
* Ian: Does this stuff actually work?
* Cullen: to a degree, it does help where it works
* Cullen: 5G stuff not included because I didn't know
about it, but similar
* Zaheduzzaman: some of these might fall into a "good to
think about" bucket
* Jana: may spend a lot of time thinking about what should
go into different traffic classes, etc. We should also
keep in mind that if we start using those, we also end
up in different queues on the network which entails some
re-ordering between them. Worth keeping in mind, and
maybe writing up
* Christian: See lots of interest in doing some of this,
but a lot of this is research, which should come into
this group when we have research results, otherwise we
should work from an assumption that all packets are the
same priority. We should narrow the discussion that way
to make it more manageable.
* Victor: another issue is marking packets can interact
poorly with congestion control
* Jana: yes, exactly, we should avoid going into these
rabbit holes. Agree with Christian.
^
I frames more important than P frames
* Ian: P-frames are useless without relevant I frames
(adding emphasis)
^
that's why streams are good, to provide strict ordering
* Victor: we assume GoPs are adjacent, but they might
overlap temporarily
* Which complicates this discussion
* e.g. may want to start cutting I frame earlier to reduce
join latency, etc.
* Cullen: yes, you may smooth sending I-frame across 5
frames of P frames
* There are games you can play to smooth bandwidth,
make different tradeoffs, yes
Jana: [clarifying question about frame types?]
Jana: still trying to understand this point
about I frames being more important because I've
now heard counterexamples
Alan: multiple ways to solve this - could
put things on different streams and
prioritize, or could put them in the same
stream and have QUIC handle that for you
Christian: [...]
L4S.
* Cullen: markings again, but some different stuff, have
heard people asking about L4S
^
New slide: Prefetch
want to be able to prefetch most likely candidates for next
thing to be played
Alan:
Slide: Prefetch Fairness
Kirill: yes, in some cases that's true, and in other cases it's
the opposite
Luke: you don't want to the current video sitting there
buffering to support prefetch, this depends on current buffer
size
Christian: we don't want to be loading a Python program in the
relay to decide these things, we're defining a binary protocol.
We want for publisher or subscriber to be able to say at some
point what their priorities are. We may want this to be dynamic.
Keep relaying simple. Put application logic in the client or
server and just provide a way for them to express the results of
that logic as priorities on the wire.
New slide: Where can things go wrong
New slide: between home relay and cloud
Next slide: between local and relay
Slide: first hop from original publisher to first relay
Slide: MoQ Deployment
Jana: in diagram which nodes are making the decision? Does the
protocol need mechanisms to support this switching?
Lucas: Yes, this slide makes total sense. Operators will do
whatever they need to do to provide the best experience. Whether
anyone else needs to know what they're doing.. we do need to
allow them to do this kind of traffic management. Because
they're going to, even if they have to use heurestics or
sniffing or whatever to do so.
Zaheduzzaman: clarification - do we not currently have this info
or a way of expressing it?
Christian: we've been doing this kind of thing for 40 years. If
we try to tell CDNs which paths to take, they'll just do what
they want anyways, so we can provide a mechanism just to express
what we want.
Mo: ...
Will: original publisher priorities do need to propagate
down, subscriber prefs are another thing
Suhas: how do we tell downstream whether something is coming
or not? If things go wrong, how do we communicate? Any
solution needs a way to allow subscribers to express their
preferenrce, relays to indicate if things are missing and
publisher to instruct relay to follow when there is no
subscriber preference
No break.
What Priorities Can and Can’t Do - Alan (20 minutes)
cannot prioritize across connections
Mo: if an application needs to make multiple
connections, is that out of scope?
Christian: personal goal to say best effort is good
enough [scribe, later: plus AQM?]
Will: publisher prioritization limited to context of
a namespace
Jana: what is a namespace?
Luke: need to be in the same namespace to be in
the same prioritization domain right now.
Can only prioritize if you have more than one thing to send
Prioritization is zero sum
Prioritization is only as effective as the input signal
Reprioritization has a 0.5 RTT penalty which limits its
effectiveness
Victor: assume this means reprioritization by peer
Christian: knowing what your bottleneck is can have 1-2 RTTs
lag
Luke: reprioritizing constantly on the receiver is something
we currently have with HLS/DASH, and we can do a bit better
here by giving the send information about what to do in the
face of sudden congestion
Victor: repriorotization can only reprioritize things that
will be sent in the future. unfortunately we cannot
reprioritize things that have been sent in the past. One
place this appears in in relation to retransmissions.
Christian: not strictly true. Many stacks have
retransmissions at same priority as original
transmission
Cullen: main point is we can't reprioritize things in
flight
Jana: signaling and decisioning priorities are separate
things
Scribe switch: Cullen, Will.
Chair expectation - by 2:30 or 3 we will address solution proposals.
Bashed agenda to talk about solutions later today.
Review HTTP Priorties.
Alot of this stuff does not matter. Hardest part is proving any of this
works. How do we meassure for real, not a lab.
Scheduling is imporant, and that is not the signalling. The signalling
is only an input to scheduling.
Send what you have, vs try and wait and do something better. Try to have
the person sending the information indicate what they are trying to
accheive.
SPDY had weieght priority 0-7. Durin standardization moved to abotu 2^30
levels.
Ian: Had use cases where turned complex things on, performance went
down, and then they turned it off.
Very flexible proigramable things were too hard to explain, developers
uinsg it could not use it. Browsers did much of it inside the browser
instead of bubling up to applications.
Some web performance metrics showed better performance with priorities
turned off.
Need real world measurements, like with real WiFi.
Stream independence of QUIC made moving H2 trees to H3 very hard.
In the end, just punted priorties in QUIC spec.
Signals come from anywhere, like memory load for example. Naive
solutions can move to be easily DOSed.
Jana: Experence here in HTTP and Web general, so some things like
repriortization might work better in specific use case like MoQ.
Ability to repriortize did open DOS opportunities.
Alan: is there a browser API to change priority.
No, but can influence them by spooky action. API like Fetch Priority can
nudge things.
Mo: Advice on coexistance of H3 and Moq flows at same connection.
When started, wanted to use same thing, but the scheduling strategy does
not matter as long as it is the right fit for application.
Latency has gotten much worse over time, but the managment was much
harder.
Scaleable codecs took more compute so not used a much today.
Rely lots on congestion control - that is what backs up the q's.
Like to see newer techniques that can speed up "faster" than today.
The priority system will gamed by the app. Systems often fail to model
other cross traffic.
Application will allways have to compete against across saturating
flows.
Persistent congestion should be dealt with by app and not trying to use
priorities to deal with long linved. Instead they should use priroties
to deal with short term congestion.
Strict priorites sound simple, but typically need fairness or policing
adding to it.
Christain: A combination of best effort and adequate queue managment.
Will: broad deployments may be better than narrow better
Jana: MoQ should be a framework that cna work for both. Like to
highlight transiant and persistant congestion. There is no solution to
persistent other than stop enseing. Transient is not predictable. So
something happen in short time frame and others like, ABR, operate in
longer time frame.
Suhas: Transient more imporant.
Will: Persitant congestion starts as transient.
Mo: Congestion controll and prirotization are very tightly coupled.
Christain: we have the multicast problem. If a million people getting
it, if one is getting poor quality, what to do.
Mo: that is application sepecific way that allow susbcriber to change.
ABR example.
Lucas: Is rate limit persistent congestion or something different?
Jana: can not solve persistent congestion with priorites.
Ian: Does jitter buffer size very and how does application adjust.
Mo: Knows jitter buffer and tolerence and receiver.
Taling about congestion control and priority. These two differnt things.
Can do rate adaptation for persistent congestion. Moq congestion can
happen differnt places. Don't solve congestion control with priority.
Jana: how do you see interactions FEC probing between controllers.
Mo: Probe up to next media reates.
Ian: Does Reed Solomon use up too much CPU.
Mo: Have other approaches that use less.
Christian: Can't apply RS to Iframe, instead do to QUIC.
Mo: open questions on how FEC gets mapped to MoQ. Could be seperate
track, or could be in QUIC but proposal have not got much traction.
Ian: MoQ might create demand for FEC in QUIC.
Mo: Erasure code tend to do packets, but could also do it at frames. But
actual loss is packets so probably more efficient to do packets.
Lucas: As QUIC chair, many requests on FEC. Encourage people to reach
out on Francois Michel who did PhD on this topic.
Showed exmaple where filling with newest first does gets worst user
experence than oldest first. There are case where LIFO is better and
cases where FIFO is best.
Worked example 2 where a bunch of video got put on link, then no room
for high priority but small audio.
Ian: Any time you have multiple rates, so if you don't think you can get
a given level thorugh for extended time, then don't send it.
Mo: We have had this problem with filling pipe. This happens when Wifi
rate jumps and upper layer has already sent a bunch. Right thing is
smaller windows, matching pacing, and faster detection at the quic
layer. We don't care about filling the link, we care about keeping the
quee empty.
Luke: Buffer bloat is you can't prioritize something in the queue.
Christian: that won't work. It takes 2RTT to detect actually detection.
When making a decision to schedule, you are making decision based on
networks state 2rtt in the past.
Cullen - we're not here to fix congestion control in QUIC.
Jana - making decisions as late as possibe is really useful in real time
systems.
Will: Agree on priortize live over VOD but don't want VOD dropped off
the use-cases.
Luke: want to be able to VOD with MoQ
Cullen - number of signals are constrained. HTTP priorities failed
because of vagueness. Need to know how relays will behave. Therefore we
need to be specific on relay behavior.
Victor - easiest place to innovate is on the sender.
Cullen - easier to innovate in JS in the browser. Winning design is to
nail one end and leave the other end flexible.
Lucas - respond we have to define someting and everyone needs behave to
it. Need to be able to ignore as part of policing. Don't want can set a
flag and break everyone.
Victor - hope to make it more flexible for relays to eperiment with
algorithms.
Moderated by Chairs
Question #1
Christian: seperate application level priority and QUIC level. The
algrothm in relay may decide what number to pass to QUIC API.
Question #2.
Lucas: veto tree
Luke: it is optimzation problem and impossible to get perfect
Victor: would want something you can comunicate to WebTransport API
Suhas: this is about what to send next when you have a few things, not
when you have nothing
Ian: can we see the space of inputs from production or production like
systems ?
Jana: two things what are the signalling, and what is the decision
algorithm
Mo answing Ian: Have all the signalling, evey stream pinnned or
prioritzed by user, sender decision will never fill pipe with more than
congestion controller will take. Stop sending as soon as it gets
feedback from controller.
Ian: Have a model of buffer depth ?
Mo: It is known due to knowing app, but not so much communicated.
Ian: So webex goal trying to slightly under fill the pipe and make right
decision.
Mo: congestion feedback to congestion controller is more than normal
RTP.
Lucas: user agent sniffing and using past history is a thing that they
do consider and use. Another signal they use, class of customer which is
not on the wire.
Luke: Tried sending jitter buffer size from receiver to sender, and
tried to make ABR based on time remaining. This did not work out. Target
latency was about 2 seconds.
Ian: In determining what to send and not overfill the pipe, did you try
and calulate what quality would work.
Luke: viewer send everything they want, server round down on what could
look, and send most recent first. Wanted to get around HOL blockin in
HLS. Deliveriing older data makes sense but you have less time to
deliver it.
Alan: seems there should be sender and receiver signal.
Will: Need to think about DOS
Luke: need both, need to de duplicate sending up
Cullen - DDOS and client trust is a problem for subscriber side.
End-subscriber signal should only effect it. Original publisher signal
can propagate because we trust it more.
Luke: if only one subscriber, then can propigate upstream
Ian: subscribe are hop by hop. Data send from Original Publisher is end
to end.
Christain: when multiple publisher are sending to same end subscriber,
hard to trust relative priorities between publishers
Jana: If
Cullen - clarification, signal from original publisher is propagated
hop-by-hop across all nodes.
Ian: End publisher info flows to all relays and they can all act on it
Lucas: .. lost his point ...
Victor: End publisher can flow info to all the relays on the path.
Christain: Mostly a subscriber signal. PUblisher puts information in
catalog, then subscriber susbcibes to the track. The end subscriber is
making decision of what tracks to subscribe to.
Mike: Some of the signals propigate, but the decisions is made by each
sender. Be more cautious about propigating
Cullen - if you ask a relay to do something and it doesn't do it, you
have a broken system. We should be clear about what is optional versus
what must be fulfilled or else return an error.
Suhas: Publish has intention of how to deliver data. Needs to have some
way to indicate what prefernces.
Suhas: Use cases are indicating we need differnt things.
Mo: very hard to discuss this in the abstract. Some people thinking
about priorities inside tracks vs across tracks. We don't have a good
word for a track set.
Ian: what info can that client not provide.
Victor: differnt clients will provide differn info. And hard to update.
Luke: goal for MoQ is differnt clients have different latency
requirements. Last hop is easy, other hoips are hard. Solution was to
let the publisher decide. Need some combination of both.
Ian: end publisher might say lower quality better than 4k and don't want
that to stop all other traffic.
Luke: but some end subsriber might want to pin 4k stream.
Jana: Original publisher signal flows across the relay chain. End
subscriber signal flows up to first relay. Then that relay can choose to
send the signal or a differnt value of subscriber singal up.
Luke: Relay forward first subscribe. One second susbcribe, update the
subscribe to just say default.
Victor: On an individual hop, if the subcribe ask, then it should be
followed, otherwise use what publisher.
Suhas: If each subscriber ask for something differnt, they will get. If
the original publish has an problem on publish, the publisher needs to
set that.
Ian: What would a relay do with a up the chain the driven. Not want to
propigate all the end subscriber all the way back to the beginning.
Cullen - if you have things that don't reliably propagate, that system
will be brittle.
Christian: On comment we don't have a channel for info to propogiate
infomation up, we do, we just update the subscribe.
Ian: arguing more than would not propigate up the chain
Mo: differnce is the relays have agregations. Two differennt susbcribers
want to differnt tracks to have priroty. If we take a concrete example
like this and try send up.
Suhas: Relay does more than just a subscriber and publisher. Ever time
we add more signal, it makes the agregation more complicated.
Chairs: We have consensus we need both publish and subscriber demo.
Chirstain:
Tim Evens:
Chairs: propose way forward.
Seems rought straw man is:
Tracks can change publisher priority over time.
Publihser Priority can not change on object after sent
Subscirbe can update subscriber priorites over time.
Lucas: the H3 extention mechanism was allowed due to lack of getting
consensus on a base algorithm. Have written two extentions that no one
seems interested in. Ends up being not be used.
Will proposal on priorities.
Fair share between connections.
Looking inside a connection.
Publisher priority is 1. Send priority is 1 for each object.
End sibscriber clients also have an end subscriber.
Subscriber orders override the send order.
Default would be FIFO drainin if no priorities.
Ian: terifing for relay to agregate upstream. Too many ways to game
this.
Ian: we probably need to talk about granularity.
Victor: look at stuff for inside the track
Luke: agreement on between tracks good, but parts inside track need work
Chairs: Will & Cullen, Ian come up with stuff between tracks. Will see
more proposal for inside track.
ADs: requests
Backup scribe lost connection at this point. Need to recover
Jona: we are using priorities for receive order and express dependency.
We need infinite numbers for that.
Cullen: all use cases can be solved with small numbers. Could be varint.
Suhas: clarify that steps are executed in order. Cullen - yes.
Martin
Moderated by Chairs