Minutes interim-2024-moq-24: Wed 16:00
minutes-interim-2024-moq-24-202409251600-00
Meeting Minutes | Media Over QUIC (moq) WG | |
---|---|---|
Date and time | 2024-09-25 16:00 | |
Title | Minutes interim-2024-moq-24: Wed 16:00 | |
State | Active | |
Other versions | markdown | |
Last updated | 2024-09-25 |
minutes-interim-2024-moq-24-202409251600-00
MoQ Virtual Interim, 25 September 2024
Bluesheet - Please sign in.
- Martin Duke (Google)
- Alan Frindell(Meta)
- Lucas Pardue (Cloudflare)
- Will Law (Akamai)
- Mathis Engelbart (TUM)
- Ian Swett (Google)
- Sebastian Rust (TU Darmstadt)
- Cullen Jennings (Cisco)
- Jangwoo Son (Fraunhofer)
- Victor Vasiliev (Google)
- Mo Zanaty (Cisco)
- Suhas Nandakumar (Cisco)
Minutes
- Ian Sweet.: Lucas, did you prepare something to present
- Lucas Pardue: No, no time
-
Lucas Pardue: Introduction, Background in QUIC
- General feedback for the MoQ proposals, proposals for change
- Issue in question: #536 Extending QUIC notation
- Critique towards existing diagramms, should adopt QUIC RFC 9000
notation
-
Cullen Jennings: Agrees in general, but
- people from other backgrounds might find QUIC notation confusing
- existing var-ints do not map well to existing systems, which are
already using 64-bit integers
-> will open a general issue for this
-
Victor Vasiliev:
- @Cullen, please document the issues for when we need hard 64-bit
integers, - @Lucas, in general agreement, but disagrees on a couple of
notation suggestions
- @Cullen, please document the issues for when we need hard 64-bit
-
Lucas: streamline notation, current notation is not expressive
- Mo Zanaty: Lucas suggestions are fine, namespaces are the only one
affected anyway - Martin Duke: issues in question are #543 and #536, correct?
- Lucas: For now, work in progress
- Lucas: Goes through #543
- Lucas: Discussion/clarification about #542, regards SHOULD and MUST
- Motion: any objections to #543 and ??? -> no objections
-
Lucas: Issue #544
- MoQ control message to adopt new notation, make length explicit
-
Martin Duke: clarification, no message has multiple definitions of
(old) b value in it, correct? - Cullen Jennings: in agreement for general notation cleanup
- Lucas: These changes do not affect wire-format, just editorial
- Martin Duke: agreement for suggestion from @Cullen
- Alan Frindell: General agreement, but when is the right time for
notation cleaning? - Martin Duke: Not urgent, but people are free to do it when time is
on hand - Ian Sweet: After next IETF sounds right
- Mo Zanaty: Flag day should come later, after big issues like fetch
etc. - Does anyone object or has concerns regarding the general direction?
-> no objections - Lucas: Last big issue #545, consistency in error naming, should you
give very specific or more general error codes? - (discussion about error code spaces)
- Martin Duke: is #545 connected to error code spaces?
-
Q: Any objection to single error code spaces? -> no objections
- Alan Frindell: Favors single space
-
Motion: any objection against renumbering error code spaces -> no
objections
Conclusion: We will move to one error code space, remove the prefixes on
the erorr code names, and renumber the error codes if there are
conflicts. Lucas will do this with one or more PRs.
- Finish up discussion about issues presented by Lucas
- Issue #501
- Alan Frindell: Common format for the control format instead of many
very specific control formats - Will Law: General aggrement for common control format
- Lucas: +1
- Cullen Jennings: optimize later, we need to talk about more pressing
issues - Alan Frindell: Maybe adopt HTTP style responses?
- Lucas: If you can be more specific than HTTP, than yes please
- Mo: HTTP responses not appropiate, because MoQ needs response
matching