MoQ Thursday

Warp

Will from Akamai:

Overview of Specifications

WARP is one streaming format along with LOC and Chat that could run on
top of MoQ Transport.

PR #27 added LoC packaging to WARP, in addition to CMAF. 'Packaging
Field Value' indicates which is used.

PR #26 is the timeline track proposal. Enables seeking, as well as
inserting events at various times.

Chat has some feedback about how CSV and strings are annoying. Will
previously mentioned CBOR as a future option.

Mo Zanaty: Maybe a separate binding to the timeline track would be
better.

Will: Not quite ready for adoption, still some work to do.

Cullen Jennings: Agree about where the draft is, but lean towards
bringing it in sooner rather than later.
Once it's clear that its the right shape, its a good point for people to
adopt.

Jordi: Are you proposing an independent draft?
Will: Yes, this depends upon Catalog.
Jordi: We could also use this without depending upon Catalog if we want.

Mo: This is a good basis for WG, but caution about few people looking at
the media formats MoQ would carry.
This is the SDP, Mime-types, etc of MoQ, and think other communities
should be included.

Metrics and Logging

Suhas from Cisco

Status Quo: Applications report information about media and quality
issues in near realtime or send at end-of-session.

Problem: Metrics can compete for application bandwidth, No shared
congestion context, everything is equally important

Proposed solution: Use fine grained control of priorities and the
burstiness of media to send logs when less busy.

Q&A

Martin Duke: Unsure I understand the communication model. Subscriber
sends data upsteam and data is cached there?
Answer: Yes

Jana Iyengar: Thinking about using MoQ for logging for a while, but it's
possible logs are in a different congestion context.
Answer: Thinking that HTTP and MoQ metrics could share a context.

Zahed: Trying to understand this better. More of a prioritization sort
of issue.

Jordi: Really like the idea of using MoQ to send metrics, but today
typically metrics are sent on a different connection.
Answer: MoQ has a next hop relay, so the relay could send metrics in a
different direction from where media is coming from.

Will Law: Really like it from a large scale view. Be nice to make this a
standard feature of relays.

Gurtej Chandok:
Suggest adding to the draft information about how end to end keying from
log producer and consumer with things like MLS

"Peeps" an Extended MoQT Object Model

Used the name Peeps because it has no baggage, and is whatever we say it
is.

Cullen: Don't completely agree what the premise of Martin's example.
Martin: Some confusion about status quo: For example, in Stream per
group, only the whole Group has a priority.
Cullen: ??

Jana: Is a peep a stream?
Martin: Not quite, because a peep could be split across streams in some
cases, and trying to avoid using an overloaded word.

Q&A

Mo: To answer Jana's question: At the Object model level, they're MoQ
data. One thing struggling with in MoQ is temporal
scalability in the current wire format. It's potentially a hacky way to
do it. Mo would like to see a different way to do it (Yes on PR)

Suhas: The Object model can have different priorities for different
Objects, if we ignore how it maps onto streams.
Use cases where you want to send all Objects at same priority, so
mapping to a stream works. Nice thing about Peeps
is that it makes it clear. A group can have multiple priorities. Yes we
should write a PR for this.

Luke Curley: Agree that is all comes down to temporal scalability. Added
Object per stream for that use case.
The different ways we map Objects to Stream are confusing. Yes on a PR,
anything to change stream modes is good,
3 different modes is problematic.

Cullen: An identifier is useful, but don't want to remove stream per
track in the same PR. It's likely a goodidea, but not yet motivated.

Ian: Fetch seems like the right use case for a single stream, so
hopefully Victor's PR will use that for older data
and then we can get rid of it for realtime data. Definitely like to see
a PR.

Christian Huitema: Like what you're proposing because Groups, Object IDs
don't fully capture

Mike: Like this, simplifies forwarding preference. Glad to help with PR.

Jana: Important to write the abstraction in the context of what we have.
Happy to help you articulate it well. Willing to help.

Track Switching in Media Over QUIC Transport

Zafer Gurel

Q&A

Kota Yatagai:

Will Law: Think the existing APIs are sufficient using a
SUBSCRIBE_UPDATE.
Answer: Seems possible, but if new track is not in cache, SUBSCRIBE_OK
takes a while.

Suhas: At a high level, I think this is a problem to solve. Not sure at
the MoQ transport we want dependencies between tracks.
There was a discussion of a mechanism to prewarm the cache for lower
qualities and make sure they're available in case
need to suddenly switch.

Cullen: Like to solve this problem. Would the freeze/unfreeze model for
a subscription meet your needs.

Jordi: Also want to solve this, but seems the only thing one needs is an
atomic SUBSCRIBE/UNSUBSCRIBE.
Could put this in SUBSCRIBE_UPDATE or create a new message.

Administrivia

Martin: Weekly interims will become biweekly during August, then go back
to weekly. Typically at 9am PST.

In-person interim. Identified NYC as a location, but haven't found a
host, so don't book tickets.

Ian: Transport

Should missing Objects be required?

#345 - sould missing object be required.

Suhas: For subscribe telling the other end missed object, not usefull.
For fetch it may be usefull.

Lenox: Is it something publish or relay put in
Ans: it is an indication you will never get i.

Martin: like explicit signalls. Happy to add don't have and won't send.
And don't have but will send later

Will: How does this work with ranges. For sparse obhjects, what is
communicated.
Ans: very sparse space, ask 1000 groups, and send bunch.
Will: why ? not usefull.
Ans: don't you want nukbers compact ? Case for explicit case

Luke: for low latency does not matter. For reliable live, want to know
if object is not coming. Doen't want to have a timer.

Cullen: There are some applications where you know the IDs are sparse
and you can wait. There's other applications where IDs don't collide. I
think we have applications where there can be large gaps to avoid
collisions and we shouldn't be publishing markers for each gaps. This
should be punted to the application. The relay doesn't care if there's a
gap.

Ian: Does a relay have to make a cache-miss request for each gap?

Cullen: That information should be elsewhere? (@Cullen elaborate)

No Limit on Subscriptions #272

No Limit on Subscriptions. SUBSCRIBE per stream?

Luke: think we probably need the setup paramterz. Don't share with
QUIC's flow control. 1&2

Cullen: Different max subscriptions and max announces limits.

Martin: Max subscribe ID not max subscriptions.

Mo: Splitting subscribes into separate control streams removes useful
HoLB.

MOQ Wednesday

Interop

moq-cat- draft-5 and -4 implemented, some testing
Call for MoQ interop Czar. Getting the interop apps similar, what we
want to interop on, maintain spreadsheet,

Payment offered: chocolate

No volunteers come forward. If you have an interop application, write
down what track and catalogue is to help make it happen

Livestreaming this meeting over MoQ

First MOQ public stream!
This and thursday session. Alpha stage. Lower expectations.

Feedback welcome

IETF network, wifi, relays in Akamai Linode to you

moq-encoder-player moxygen both from Meta (opensource)

No priority implemented yet, so audio and video both cut out if things
go bad

Can play with it: https://g28g.short.gy/moq120

the MOQ journey

moqt-00 July \'23

Bunch of new featurs, object model, subscribe, status, priroities,
mechanical and eitorial improvements

Consensus on layering
Adoption of Catalog
LoC and WARP open

Lots of feedback from implement and interop

Issues where we can get PR and consensus. 8-10 marked plus a few.
Volunteers needed. 6 volunteers

Cullen, Mo, Suhas, Coda, Christian, Mike English all volunteer

Where going: refine partial reliability, FETCH vs SUBSCRIBE, publisher
(make before break, multiple in meetings), security, auth

Cullen Jennings: Lookahead parsing issue. Harder to solve later.

Issue where someone can write text

Higher levels: Catalog - adopted, good place. Interop soon?

LoC - out there, part of demo

WARP - further away

Zaheduzzaman Sarker: thanks for update

MoQ Transport-05 updates+priorities

-03-04 SUBSCRIBEv2 simplifies subscribe
Clarification and an SUBSCRIBE_UPDATE

-04 to -05: Priority and group send order, terminology updates, object
status

Status lets us say when things are missing, not just a gap

SUBSCRIBE specifies a Priority
also Group Order

SUBSCRIBE_OK gives publisher one

Subscriber preferenced on theory it knows more

Alan Frindell: priority field went from varint to byte. Thanks to who
ever sent priority >62

Select subscription->group->object respecting priorities. Logic in the
slide

Tianji Jiang: Object payload and metadata, group object, id. Why not
extension field for metadata? Ignored by transport but for higher level
things

Cullen Jennings: Slight correction on send order for objects from
slides, send by object priority then object ID.
Mo Zanty: debate over who gets to touch metadata

Common Catalog

Will Law presenting.
Warmup to actual transport. Hypothetical but now in QUIC.video

Lots of changes and PRs merged, two for discussion, and three issues to
talk about.

Reminder of where the document is: now in IG github. Standards track

Delta required indication for simple players.

New root to hold inherited track fields. Another issue about not merging
this one

Packing or format? Track has objects with payloads. Want to say how
packaged: cmaf or loc very media specific. And more than packaging
matters. Replace with format to make it broader if you want

Victor: strings very flexible

Will: Version of application namespace for format. CMAF, CMAF mean
different things without namespace. No objection with IANA registry

Lucas Pardue: why not media types? We’ve got a registry already!

Will: MIME different: selection parameters. Beyond MIME. Still vary
package in MIME

Suhas Nandakumar: packaging fine name. Should be something in IANA.
Experiment not registry, but loc should mean loc.

Victor again: Just because different application doesn’t mean they share
types. No reuse because MIME is for files, sequences of bytes. MOQ is
things with a deep structure

Cullen: Nit sorry to be raised. Codec:opus in parameters, what do you
call that field?
RTP says format, using format registry, other format term already used.
Maybe moq-format
Will: track format?

Bernard: might be codec string. Not AV1 but full profile etc.

Will: yeah, intended

Mo Zanty: lots of confusion. Loc: what codec? Doesn’t specify. MIME not
appropriate because these are things never IETF specified. Other bodies
do it no IANA needed. Web codec tried in W3C for relevant subsets but we
don’t need to duplicate that. Explicit about what we reference. Codec
isn’t from any body, just word as tag in catalog

Will: Applications pick it

Mo: think we need a design team for all packaging, format, description
things to sort out what this all means. Especially given the questions

Magnus: don’t use media types: they don’t mean right thing. URN works,
IETF prefix for standardized. Anyone can make unique ones themselves

PR 63: type for tracks

Will: lots of use cases to say data or timeline track. Scope of
streaming or game using catalog to describe content. String, type
optional. Any application define contents

Victor: is field application specific

Will: yes

Victor: let applications add arbitrary fields with structure for this.
No need for standardization

Will: Extensible by application: we define base, can throw in JSON
everywhere, up for client understanding to use and parse. Clients that
don’t should ignore.

Victor: yeah, that’s position

Luke: use case is type safety. Parsing and knowing we want audio and
video. Any track any field: audio a width. If nebulous a pain to
implement. Understand Victor but we should define audio has something to
avoid lots of JSON. Some sort of thing exists for selection

Will: in application spec, or catalogue spec?

Luke: somebody must! If we don’t interop fails.

Will: WARP, not catalogue. Maybe a question. Streaming format defines
this. Parser against this app, not generic catalgoue

Mo: just like extensibility in lower level needed for catalgoue. Agree
some want blobs. Let’s make clear namespaces don’t collide

Will: add comments to issues, we’ll follow up

PR 46: field for track prioritization.

We need so producers say what’s more important

If any track needs, all do it. Equal priority can be done. Absence means
all equal

Suhas: make mandatory

Discussion about priorities and parsing.

Issue 33: commonTrackField premature optimization. If we wanted it
smaller, do binary. Repetition doesnt matter much.

Culleen: in agreement

Issue 44: string not integer for streaming format

3 fields. Lots of options. UTF-8 wanted

While doing this add in the version! And then can imply the catalog

Stuart Joshua: Strongly argue against option 4. Not UI, protocol
identifier. Numbers need allocation. Strings waste space but nicer.
UTF-8 and arbitrary scripts comes with problems and not worth it. DNS
discovery service types: US-ASCII letters and digits. Expressive enough
for memonic but not unlimited length

Cullen: UTF-8 will have interop bugs forever as people won’t test.
Semanticly different things in different fields, Versions can be
reasoned about, migration easier

Mo Zanty: don’t want to merge catalogue and streaming format.
Semantically incorrect. Want to parse catalogue before finding out
streaming version

Consensus for option 2: keep version separate ASCII name

WARP bumped to Thursday for technical difficulties

Secure Objects

Cullen

About e2e encryption. Equivalent of SRTP for RTP

Not replacement for cenc for CMAF

Minimize bw for MoQ esp. Audio

No new crypto
Integrate with MLS
Integrate with containers

Relay independence

Why not RTP to S/MIME? Because it gets big!

AEAD crypto: track used to derive keys, object and group id used as
nonce as they already exist

Lyria: 3kbs. Crypto doubles size

Emad: why not SFRAME

Answer; need some extra data to go in

Victor: don’t want to redo Sframe

Richard Barns: end up needing to remove some stuff and put it from moq.
Got PR to replace guts with it

Wrote by copying Sframe

Victor: don’t know where but useful. Don’t know about HKDF every time.
Only hard is auth tags

Catalog says how:

Richard Barnes: cant just use track frame, as need different keys over
time in MLS

Mo Zanaty: took this as an instantiation of sframe in MOQ context. Key
context things needed, this defines them and the derivation. Binds to
MOQ object as instantiation. Not competitive at all. On way layed out
struggle in Low Overhead Container. Just as MOQ needs extensibility for
headers maybe trailers, auth tag as trailer vs blob with all of it

Cullen: RTP says we did it wrong way

Suhas: metaquestion about how to do it, yes, once adopt can figure out

Ask adoption, but think some people need to see sframe connection worked
out. Hadn’t though about Mo’s idea, but think it’s good, but relates to
MOQ things.
Mo to file moqt issue for trailers in transport

Many faces of subscribe

Victor presenting

Subscribe is better in 5. But there are some corners

Current group, current object, absolute start, absolute range

Current object easy: track is somewhere, look at biggest object
delivered, send it (or not: unclear in spec) send newer objects

What if you ask for (1,000, 0) to (2,000,)? Do we open all streams, open
as the objects come, how does backpropagation work? Flow control
interactions!

Don’t know grouping of future objects!

Ian Swett: Think with group order need to send all data on group 1000
then 1001 1002 etc. think shape of problem is true but example is messy

What was written was supposed to clarify this. Writers intent, maybe not
reflected

Track at (10, 1000) stream per group

Current group, but miss on (10, 0), so has to grab a bunch of stuff, but
publisher still ahead. Takes a few rounds to converge, especially with
cache pressure.

What about objects that don’t exist in absolute requests? Holes in
cache, or publisher knows they don’t exist

Mo Zanaty: I thought this was going to happen when moqt doesn’t go for
live edge. As media is being produced. Not VOD. If VOD those are fetches
not subscriptions. Preserving subscribe only for live edge removes
issues, but when you do a FETCH assumption of line rate and parallel.
Most likely not what application wants. Then MOQ extended for media
rate. Separate this from FETCH. Lots of impacts between catchup, live,

Not even current group, no current object only or start of next (stream
said, group meant)

Suhas: brings back memory of last interim. As Mo said FETCH rich, and
that doesn’t exist for SUBSCRIBE for live data. So anything with live
range works older. But overload same as live has issues

Cullen: Each time you request thing in past comes back, sense as thing
in future, past and future different

Luke: for fetch suggestions has to be radically different otherwise same
issues as subscribe with flow control and cache misses/pollution. World
where easier but little harder than separate

Martin Duke: Current group gives you whole thing, or issue
Victor: might be long, might be constantly backfill
Martin: but it can get new in really
Victor: 5 clients all up to date on object 1000, new client says 0,
0…1000 dropped from relay cache…

Live and VOD
Live: new objects, a little bit of the past
VOD: fetch range from past

Past idea; subscribe and fetch

Atomic subscribe and fetch: grab the new, while catching up on the old

2 drawbacks: stuff can be reordered, producer might not close out old
group after new one opened

Fix: subscribe used to mean things in the future
Proposal: subscribe means things future at publisher, at relay as
delivered from publisher

Solves reordering issue

Fetch: - lots of properties not for just grab things

Actual proposal: backfill

Send what you got from N groups ago. Easy to implement, look in memory
and forget anything you don’t have.

Timeouts and priorities remain meaningful.

Concretely:
FETCH with range
Alter Subscribe:
N most current
Backfill semantics

Suhas: i like
Luke: don’t like that backfill depends on cache. Cache needs to be
transparent.

Mo Zanty: Like idea, maybe not specific. Should revisit this issue

Culleen: Promising direction, agree with luke and will on cache

Will Law: Support notion that cache is immaterial. Optimization.
Shouldn’t impact received or requested.

Ian: encouraging, observation absolute start is problematic with
subscribe is great. From writing before whole new message with
acoutrements is a wall of text. Maybe easier to make absolute start end
is other verb. Smaller diff