IETF 121
Chairs Alan Frindell, Magnus Westerlund, Martin Duke
MoQ Session 1 (Monday 17:30-19:00)
Administrivia (Chairs) 5
Slide link:
https://datatracker.ietf.org/meeting/121/materials/slides-121-moq-chair-slides-00
This meeting's mascot is Leo the Leister Lion (Rugby Union)
The group briefly discussed the possibility of sponsoring a prize for
scribes, with winners drawn at the end of the week. The Chairs reviewed
the Note Well notice for the group, as well as the "Note Really Well"
notice, which discusses professional collaboration.
They then reviewed the logistics of participation via the Meetecho tool
and the agenda for the two meetings this week.
Interop (Mike / Mathis) 10
Slide link:
https://datatracker.ietf.org/meeting/121/materials/slides-121-moq-sessa-interop-results-00
Mathis reviewed the test cases in use and those which would be proposed
for future interop testing; he also noted that we need to have interop
tests including relays. Suhas had some slides on that, and he spoke to
those (TODO: insert appropriate slide link). He noted that there was
more support of raw QUIC at this hackathon, including some relay
support. Jordi asked if we should have a media interop set of tests,
based on his draft. Mathis agreed that this would be good and that it
would make some other tests easier. Will suggested that we could use
WARP and catalog as baselines. Suhas noted that one failure mode was LOC
not being interopable, so we would need an interop target for both to
succeed.
MoQT Updates Since Vancouver (Ian) 15
Slide link:
https://datatracker.ietf.org/meeting/121/materials/slides-121-moq-moq-transport-updates-since-vancouver-00
The substantive ones are summarized in the deck; editorial changes were
not. Ian reviewed the set of changes briefly, then explored the
mechanism by which Announce works in more detail, given
SUBSCRIBE_ANNOUNCES being added. Key change: the announces now use
track namespaces as a tuple, so that the protocol allows you to match on
the publisher independent part.
JOIN (Will Law) - 30
Slide link:
https://datatracker.ietf.org/meeting/121/materials/slides-121-moq-join-api-proposal-00
As SUBSCRIBE is written, it allows a bit of the past, but focuses on
future objects. He proposed that it be redefined so that it is entirely
future objects (see slide 3 for the options considered). If that is
accepted, he proposes a mechanism to update the current APIs to use JOIN
(see slide 6 for the first version of the proposal, which uses FETCH
under the covers). PHB asked about explicitly requesting an early frame
and then a later frame with no intermediaries (original iFrame and a
later delta frame, but not the others). Mo suggesting an alternative,
which would be more applicable to layered codecs, which might be
implmented using filters.
Will then presented an later API proposal, which updates FETCH to accept
an existing subscription ID (see slide 8 for the details). Jonathan
notes that this avoids a roundtrip, and proposes a small change to give
the offset from subscribe rather than live. Ian believes that this is a
compelling change, but notes that this isn't very different from the
reverse (FETCH followed by SUBSCRIBE, but there would be a possibility
of overlap). Will replied that this is cleaner. Martin Duke, as a packet
plumber, is concerned that there are more complex scenarios than are
being covered in these slides; Will notes that the use case is "join the
live edge at a group boundary", and he needs that satisfied. Cullen
notes that the FETCH/SUBSCRIBE variant seems easier to reason about than
JOIN. He feels that the implmentation pain of the SUBSCRIBE and FETCH
option will also be very small, so it seems worth doing it. Mo expressed
a concern that the true delivery semantics are being flattened, since
FETCH doesn't have the same priority semantics as SUBSCRIBE. Will notes
that 95% of the current cases uses equal priority, so the risk of
flattening this is in exotic cases. He also notes that they should set
higher priority for FETCH than Subscribe. Mo replies that there are
cases in which key frames arein their own group, and that this would
actually induce latency in that case. The scribe asked a clarifying
question to confirm that this does not replace the current mechnisms, so
they could be used when the client had a reason to know that it was a
standard linear encoding. Suhas also noted that it was possible to
cancel the FETCH if you discovered it was causing a problem. Tianji
Jiang notes that in the mobile case, the five percent will be handled by
information about the codecs in place. Martin Duke, as a participant,
expressed some concern that we may not be using the right delivery model
if this is based in FETCH rather than SUBSCRIBE. Will notes that he
would be willing to revisit using SUBSCRIBE going a bit further back,
but that this was debated extensively in the past which is why this
proposal came forward. Suhas argues that this doesn't change FETCH or
SUBSCRIBE, but is simply an API for how to combine them. Jonathan noted
that you could combine multiple SUBSCRIBEs with the FETCH and that this
might enable you to have different priorities.
A show of hands on this interested in persuing Proposal 2 on the deck
was 21 yes, 2 no, 6 no opinion. The chairs concluded that there was a
lot of interest; any additional issues can go to the list, but absent
those, Will and his co-authors will provide a PR.
Priority (Alan / Victor) - 30
https://github.com/moq-wg/moq-transport/issues/585
https://github.com/moq-wg/moq-transport/pull/518
There were two clarifying questions on the title slide, and Alan noted
that he will not include title slides in the future.
If 2+ tracks are equal, select current language requires you to select
the track with the highest priority. This is computational expensive.
Issue 585 suggests that you use explicit subscription priority, rather
than relative priority (see slide 6). An alternative is to get rid of
track priority entirely, and to use subscriber priority and subgroup
priority instead (see slide 7). Alan then reviewed how the two proposals
differ (see slide 8). Cullen asked a question about the example on slide
9; he argues that this is really about which packets you don't get in
constrained environments. Martin got in queue to argue about that, but
was asked to hold his question. Mo argued that the key question is
whether order or priority dictates the order. Alan then finished the
slides.
Martin agreed that we should not keep the status quo. Alan notes that in
both cases the natural order is easy to express for either and the
reverse order can be expressed with some warts. Ian Swett believes that
both are totally workable and that the first is slightly better
expressing the will of the publisher. Suhas expressed a requirement that
he be able to get the base layer out in all cases; he believes that
group order has made that possible and suggests that the situation would
be improved if it were dropped. Cullen notes that proposal 1 trashes the
realtime use case that requires the base layer always arrive; proposal 2
works for him. Will Law, simplicity enthusiast; he also feels that
backing out subgroups would make this much simpler with prioritization.
Victor agrees with Cullen; he opposes proposal 1. Mo also agrees,h he
will forward the reasoning to the list, but basically experience with
sharding has multiple issues. He feels we should never have group order
trump priority. Suhas also supports proposal 2.
Alan notes that people are obviously speaking for proposal 2, and the
previous support for propsal 1 didn't have anyone come to the mic. Jordi
noted that he would actually like to see some simplification. A show of
hands with the question "Do you prefer proposal 2?" 19 "no opinion was
19, and yes was 10". No proponents of proposal 1 were evident. Martin
asked folks to review the issue and PR and to come back Wednesday ready
to do another show of hands.
MoQ Session 2 (Wednesday 13:00-14:30)
Administrivia (Chairs) - 5
Show of hands for Priorities Proposal #2 as the way forward: 8 yes, 1
no, 18 no opinion
Process / Workflow (Martin) - 15
Zahed (as responsible AD): Likes this process.
WARP + Catalog Merge (Will) - 15
draft-law-moq-warpstreamingformat
draft-ietf-moq-catalogformat
Alan: MOQ-Media-Interop is intended as examples for testing not a spec.
Will: Warp draft will add a section for examples with content from the
Media Interop draft.
SWITCH (Will) - 30
Martin, Cullen, Ian, Suhas: Would like to compare this to what can
already be done today with the current spec.
Jonathan Lennox: Consider separate priority for new track.
Zaher, Jordi: Like this, it's needed.
Will: Create an issue to document gaps in what can be done with the
current spec.
Timestamps (Ian) - 15
Will: Time is payload specific, group boundaries are a better
abstraction for generic objects with switching points.
Suhas, Mo: LOC adds a timestamp extension in the MOQ header, but it's
media payload specific.
Jordi: Don't mix this transport time (for cache and delivery timeouts)
with media payload (capture, decode, or presentation) time.
Magnus (as chair): Details of the definition matter and need to be
fleshed out before merging.
Ian: Will create a PR with details.
STOMP (Shamim) - 10
(draft-shamim-moq-time)
Skipped due to presenter.
If Time Permits:
MoQ Relay Network Handling (Tianji) - 5
Presented, take interest and discussion to list or github.
LOC (Mo) - 10
https://datatracker.ietf.org/doc/draft-mzanaty-moq-loc/
Presented, take interest and discussion to list or github.
Draft Files (Cullen) - 5
https://datatracker.ietf.org/doc/draft-jennings-moq-file/
Skipped due to time.
MoQT issues (Ian)
Skipped due to time.