MoQ Interim 22 January 2025
Chair Intro (5 min)
MoQT Issues/PRs
PR #638 Joining Fetch (Mike English)
PR #643 Message flows and endpoint state management (Was: ANNOUNCE)
(Martin)
If time allows
Issue #630 FETCH_CANCEL vs STOP_SENDING (Alan)
Issue #632 Lost FETCH_HEADER (Alan)
Wrapup (5 min)
Will will scribe
Martin: asking for deployment barriers, to help prioritize Denver
meeting.
Victor: what do you expect us to deploy MOQ when no application drafts
ready.
Alan: H3 lagged QUIC. We used H1 over QUIC to get experience. You don't
need to wait. At Meta we are looking at deploying MOQ but not using WARP
since don't fit. Want to reduce RTs for publisher-speak-first.
Suhas: +1 for publisher-speak-first. Cisco has experience in
conferencing over MOQ> MOQ as is today doesn't meet all our use-cases.
We have protoype fixes in testing.
Victor: Google also working on something that interacts with production
but not released independently. Round trip for catalog is unnecessary.
Martin: you can deploy MOQT with a proprietary application. If you are
blocked on having an application, then we welcome a draft in that space.
Alan: can we address PSF at Denver.
Cullen: we can't take stuff out of lab until we have an auth scheme. It
is 80% there.
Alan: auth should be topic in Feb.
Gwendal: for live streaming OTT we are at 30%, no clients, CDN, no
switch, no auth.
Mike English: presents slides on JOINING FETCH. Made a few minor tweaks
since last presentation. Clarifying edge case behavior. You now get
FETCH ERROR if the SUBSCRIBE has no content.
Magnus: are these filter types defined? Mike - yup. Magnus - spaces
between. Need an editorial pass.
Ian: can we make the subscribe do the fetch? Single Verb?
Mike: it was the consensus at prior meeting to not include more than
current group in SUBSCRIBE
Suhas: there is a PR about coercing SUSBCRIBE to a the latest group.
That PR should be considered. Also add some lines as to why someone
would use a joining fetch.
Martin: PR will merge on Friday. Please submit additional comments
bnefore then
Martin Duke (as an individual): PR 643. Presents slides. New section to
clarify message flows and state management.No more SUBSCRIBE_DONE.
SHould send ANNOUCE if NS is subset of SUBSCRIBE_ANNOUNCES, send
SUBSCRIBE if exact match.
Alan: bullet 4 - no chnages form current draft?
Martin: correct. Mostly editorial. This draft doesn't fix infinite
loops. Anyone have a simple tweak to fix?
Cullen: I can't see slides.
Alan: If you shouln't send same annouce twice in same session, does it
prevent worst case?
Martin: no, A thinks it has two sources.
Cullen: we ruled out intra-relay scope in our charter. Using MOQ
directly is wrong. Relay2relay traffic can't only be MOQ. I don't' think
we should solve this in the protocol.
Magnus - we need a wireline constaint.
Victor: when did we become routing working group. This is not relevant
to our protocol. Most people would opt for a centralized solution.
Ian: do we need a PR to prevent getting into this situation in the first
place.
Will: in favor of not forwarding announces or SUBSCRIBE_ANNOUNCES. Gets
too complex to be suffuciently well addressed in this work group. We
should remove from draft. Only have ANNOUNCE.
MO: are we underspecified for entry-to-leaf behavior, what happens on
connection loss, is a leaf relay authorative over its connection? Don;t
need mOQ signal for internal relays.
Cullen: the relays get treated as a black box, but msg on one side of
relay cloud may cause msg on other side to be released.
Martin: thanks for feedback. I'll review the PR.
Magnus: do you mean subscriber as defined in draft, or announced
subscriber?
Martin: subscriber is a role. Subscribers want objects. Relays are both
subscribers and publishers.
Suhas: I will also review PR
Ian: I don't understand what announce is for in the first place. This PR
says how it might be used.
Martin: it's useful for POCs so far.
Cullen: we need to crisp on what announce is for. It is for relays to
know where to route a SUBSCRIBE. We should clarify that in the PR.
Alan Frindell (individual) presenting slides Fetch 1) Implementaiton
Issues - what if a FETCH header is lost? Do nothing, reset, or use a
bi-di stream for fetch, reset is joined to the request. 2) Can we remove
FETCH_CANCEL and just use STOP_SENDING? We can do nothing, remove
fetch_cancel, or use a bi-di stream. 3) Consideraitons for fetch on a
bni-di stream. For jomingfetch, the fetch might arrive before the
SUBSCRIBE. We could use SUBSCRIBE ID to indicate order. Where does
FETCH_OK go? leave on control, put on bi-di anywhere, or put on bi-di
at beginning (introduces HOLB) Just looking for opinions
Victor: what about interaction with FETCH cache?
Alan: i haven't implemnted one yet.
Suhas: bi-di seems like a good idea. Bi-di for data streams, not control
streams. Bi-di would simplify fetch.
Cullen: opposite of Suhas. Like separation of control plane and data.
Not seeing enough benefit to warrant that big change.
Alan: can work thar client opens a bi-di stream for fetch and still
opens a control stream.
Victor: state management is bad in code base. Managing life cycle of two
independent things is annoying. We could simplify lot of state
management by using control and data on same bi-di stream. May be issue
with joining fetch.
Cullen: we can't do subscribe that way.
Alan: please comment. I will park for now.
EOF.