Minutes interim-2024-moq-17: Wed 16:00
minutes-interim-2024-moq-17-202408211600-00

MoQ Interim 21 August 2024

Attendees:

1. Martin Duke (Google)
2. Will Law (Akamai)
3. Alan Frindell (Meta)
4. Victor Vasiliev (Google)
5. Daniel Fay (Meta)
6. Dinesh Adhithya (Zoho)
7. Mathis Engelbart (TUM)
8. Mike English (id3as)
9. Suhas Nandakumar (Cisco)
10. Ian Swett (Google)
11. Sebastian Rust (TU Darmstadt)
12. Mo Zanaty (Cisco)

Minutes: (MoQT Issues - Ian Swett)

Peeps PR

Martin: Current PR includes normative language describing object
relationships.
Mo: Should have some guidance on delivery order, but not on object
dependency. Limited normative language.
Suhas: Agree with Mo. Peeps represents priority construct, language
should address that
Victor: What is the SHOULD being proposed
Martin: Describes sensible strategy for object dependence and delivery
order
Victor: Is this for applications or for MoQT developers
Martin: For applications
Ian: Prefers less text. Text doesn't need a SHOULD, describe behavior of
stream/peeps w/o normative language
Martin: General consensus against normative language
Ian: Example is worthwile
Will: Question need for peeps, peeps are an application feature and
should not be codified into transport
Martin: Transport API needs feature to map to streams
Will: Transport doesn't need to know stream mapping
Martin: Current transport doesn't have a mechanism for mapping to
streams w/o object per stream
Mo: See Martin's past presentation, peeps addresses temporal scalability
issues
Martin: These issues are solvable with object per stream, but that is
cumbersome
Victor: Dependencies are a transport issue, problem is how do we
communicate that
Mo: Dependencies are not proper in transport, transport doesn't have or
need the context for application dependencies
Mo: Include simple (one line) normative statement on delivery order in
draft
Martin: Examples about use of streams for dependency can be helpful
Alan (individual): Agree with Ian. Streams imply order delivery,
describe that with some example to demonstrate. Don't include normative
language
Suhas: Agree with Ian and Alan. Peeps are delivery construct, give
non-normative example
Ian: Keep normative statement on increasing object IDs

Martin: Next issue, allow peeps to be in a single datagram. Leave out of
PR, revisit separately.

Martin: Added end of peep object. Included at end of peep to limit
stream inflation.
Alan: Do missing objects need peep?
Martin: No, they will go with peep of previous object
Ian: They will come in order, but not necessarily in the previous object
peep.
Martin: Needs further discussion, add questions/proposal to PR
Suhas: Keep logic the same for one and multiple peeps
Alan: Current logic uses group ID, this changes to peep ID. Does
application need to pass this info
Mo: Nothing in PR describing peep ID, can be anything?
Martin: Current PR, yes. Will discuss later
Will: Is Peep the final name?
Martin: We will change it, plan to merge with "peeps" name and will
discuss renaming prior to publishing
Suhas: Don't want "peep" in published draft

Martin: Currently have peep ID and priority. If peeps can't have same
priority, then can make peep ID represent priority
Alan: There is use case for equal priority peeps.
Victor: Peeps should not have same priority, so peep ID can take the
place
Suhas: Alan use case can be addressed with multiple tracks. Peeps use
case is to group objects with priority
Alan: Current MoQ design is to give lots of developer flexibility.
Inclined to leave flexibility to developers to decide track/peep
separation. Current implementation defines priority and tie breakers, so
not exactly same priority.
Alan: Even if peeps can have same priority, can that be collapsed to one
field? Priority field is small
Suhas: Don't have a use case for why you can't have equal peep priority,
but don't want it.
Alan: Different field sizes may necessitate this. If we don't allow it
need normative statement against it
Victor: When using peeps, peep priority replaces objects priority as
tiebreaker
Alan: Don't believe priority can be implemented by merging IDs. Making
peep ID priority means making priority a 62 bit field
Suhas: Agree with alan, use peep ID as tiebreaker. Making priority size
of ID is not a good idea
Martin: Leave text as is, two fields should be separate things
Ian: Leave fields for now, can be revisited
Martin: In current text, peep ID is just number
Victor: Don't like two unrelated numbers.
Martin: Peep ID is on wire for relays
Alan: And caching replay
Martin: No change, general opposition to assigning meaning to peep ID
Martin: Will will propose new name for peep over list, if reach
consensus can change PR
Alan: Peep ID should have some meaning, not meaningless identifier. Will
propose outside meeting
Ian: Interleved streams makes priority complex, is case for unique peep
IDs
Alan: Solved by peep ID replacing object ID as tiebreaker. Will draft
thoughts offline
Suhas: Think multiple peeps with same ID is potentially viable.
Will: What are use cases where peep doesn't correspond with stream?
Martin: Streams and peeps correspond perfectly
Will: At transport level, calling it stream simplifies meaning
Martin: Peeps was intentionally chosen to be unrelated to all existing
terms
Mo: MoQ people have no opposition to stream, but potentially conflicts
with QUIC streams
Martin: Alan make offline proposal, Will propose new term and start
bikeshed

Subscribe namespace

Alan: Subscribes and namespaces are matched based on
< Missed some discussion here in notes >
Will: Relay doesn't need trackname
Alan: Do we need namespace and name to be separate? Can subscribes match
arbitrary subsets of name tuple
Will: Matching on n first elements of tuple is simple to implement
Mo: Core issue is handling wildcards. Addressing wildcards handles
wildcard subscribes.
Alan: Subscribe namespace is a solution to wildcard subscribes
Suhas: Should be fixed mapping, arbitrary mapping is difficult to
implement and not performant
Ian: Please keep it prefixed matched.
Alan: Mechanism to enable behavior we don't currently have, can extend
in future.