Notetakers: Emily Heron, Suhas Nandakumar
Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-sessb-chair-slides-01
The WG chairs (Martin Duke and Magnus Westerlund) presented the chairs slides.
Noted that the agenda had been updated compared to the previously published one.
Status update - two docs adopted
Low Overhead Media Container - https://datatracker.ietf.org/doc/draft-ietf-moq-loc/
WARP Streaming Format - https://datatracker.ietf.org/doc/draft-ietf-moq-warp/
Martin brought the question if we should change the name of the protocol (not the WG).
The motivation for this discussion is that Media over QUIC can be seen as a misnomer
as there exist usages for other things than Media. So the question asked to the WG
was "Should we start a discussion about the name?". Before a poll was made
a number of persons got the opportunity to express themselves arguing for
no change, just keep use the acronym as a name, it could be changed, change it and
use proffessional firm find a name.
Poll - Should we start a discussion about the name?
Yes - 12
No - 29
No Opinion - 1
Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-moqt-updates-since-bangkok-00
Alan presented on changes from draft-11 till draft-13. Draft 11 was
published in April, Draft 12 in June, and Draft -13 in July. Draft -11
was a major change to the wire format. Draft -12 introduced
Publish. Draft -13 updated track Status to match subscribe.
There was no questions.
Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-privacypassmoqietf123-00
Cullen Jennings present an alternative authorization token that is a complement to CAT tokens.
The goal of this proposal is to provide a token that can provide anonymous authentication without
loosing fine-grained access control. Privacy Pass provides a way to issue and verify tokens without
having to encoded any user identity in the token.
Alan Frindell asked regarding the matching if the prefix matching
could be done on any boundary or on determined set of name whole
tuples? The answer was that this should match CATs matching rules.
This lead to a discussion that the WG need to find a specified method for
representing the names space tuple sequence in written form. This includes
both how the tuple's are seperated as well the fact that the tuple value is
binary. It will be needed not only for specs and presentation but primarily
for logs. There was discussion if this could be a URI or an URN.
Ben Schwartz noted that the tokens are transported over both MoQT
control packets and HTTP. Thus the token will contain other meta data
like the moq-scope that contains namespaces and tracks. Need to be
careful so it doesn't allow linkability. Cullen responded that
only the relay can see the token when sent of MOQT.
Cullen wanted to know if to continue working on this, and there was
expression of support for this work. Ted noted that it might
be relevant to note why it likely is not appropriate to have
the same functionality as in CAT.
The chairs concluded that additional feedback and support to be sent
to the mailing list. The chairs will consider WG adaptation.
Slides:https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-ocsfovermoqtietf123-00
Suhas Nandakumar presented a proposal how OCSF cyber security event
data could be distributed using MoQT in way that provides low latency,
data caching in relays, available for analysis and later follow up.
Martin (as chair) asked is this the same layer as warp? Which was confirmed.
Alan Frindell asked about the proposed structure in namespace itself,
also structure in track itself. Why not use that struture in
namespace? Suhas: its possible.
Ian Swett noted that it is unclear what the asks are of the moq
working group. MOQT works pretty well for this use case, do we need to
do this? Suhas answered application that cyber security asked if we
can do it. Mo commented that these use cases make a lot of sense for
what we see from providors like splunk. Would IETF be interested?
Would others have s similar need and interoperate those formats. Makes
sense to have a wg if other providors are interested. Cullen: Doesnt
require changes to base transport, will have very different
characterists if you put on a relay. Doesnt change base protocol.
Magnus (as chair) this appear outside this WG. Good question about
when WG should care about this usage and protocols. Will continue
discussion.
Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-secureobjectsietf123-00
Draft: https://datatracker.ietf.org/doc/draft-jennings-moq-secure-objects/
Cullen Jennings presented the proposal for how to handle securing the object and its extension headers. The core
of the proposal is to classify any header extension into one of three categorizes:
1. Relays can see them and can modify
2. Relays can see them but can’t modify
3. Relays can’t see and can’t modify
Alan Frindell commented that the Integrity Marker is a new extension
type that need to be defined. Cullen responded when you go to decrypot
this you need to know what type of message to decrypt. Doesnt change
anythikng in the base draft or how relays work. Adds extension header,
and for e2ee secure object draft defines. Alan noted that the
Enc(ryption) marker is just an convention to know what shall be
encrypted and will be removed before encryption and thus never
transmitted over MOQT.
Mo noted that this stresses how to handle mutable/immutable
extensions. A important distinction is if some extension can be either
mutable or immutable depending on usage, if not one could define
different registry intervals for extensions depending on if they are
mutable or immutable. Else using a single range and a integirty
indicator is the more flexible design. Ian Swett asked what goes into
which draft. Cullen thinks all in the secure objects. Victor Vasiliev noted
that MOQT will need to preserve the serilization order of the extension
header for a solution using indicator extension. Also Extensions headers
inside the encryption are not part of MOQT. Several agreed that
a indicator extension would be part of MOQT specification.
Conclusions: Update the PR
(https://github.com/moq-wg/moq-transport/pull/1025) based on today's
discussion. Will return to this topic at a interim meeting.
Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-moqt-issues-for-madrid-02
Can you self-subscrine or self-publiush through the relay?
Will: yes
Ian: not necessary, this is scary don't want to handle loops. Why not use two different sessions?
Cullen: Yes, but doesn’t matter.
Victor: No, do not want to have write detection and handling of this.
Jörg Ott: Yes
Jordi: No
Suhas: Yes for testing purposes, multi publishers and is relay implementation specific.
Cullen: Correcting earlier statement - if there are two different people publishing to track, would want to see the other half of the objects to the track. Change answer to strong yes.
Mike English: seems like extra work to prevent it. Should be able to self subscribe
Mo: Everyone appear to only be thinking of an original publoisher. If this is relay to relay you would want those objects. Not a loop, its relay to relay. How would mutli session fix the loop?
Victor: A reason for a publisher to subscribe to a track is to see the IDs the relay puts on the objects.
Ian: best way to resolve is to allow it for now and move on.
Conclusion: Allan conclude that it appears the way forward is to allow
subscribing. We can discuss on the PR if one is expected to get the
objects oneself has published.
Cullen: This came up in a DDOS discussion - what do you do?
Alan: you ask for something big, you get something big
Will: I would like there to be a fetch error
Suhas: +1 to Will
Jordi: put what is the maximum in setup message
Mo: Didnt we have something that we could clamp down to narrow range?
Will: No. Fetch is already really complicated. Dont want to subset fetch.
Jordi: correct previous statement - not sure which direction
Ian: Very hard. How will you know?
Alan: fetch gives largest response
Conclusion: Alan - will write a PR that writes an error code.
Notetakers:
Session 2: Emily Heron, Suhas Nandakumar
Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-chair-slides-session-2-01
The chairs reminded everyone about future planned meetings:
Virtuals: 6 August, 27 August, 10 September, 1600-1700 UTC
In-person Interop: 22-23 September, Toronto
Hybrid Interim: 24-25 September, Toronto
Continued discussion of one aspect of the name debate. Should we repurpose acronym or leave as media over quic? People at the mic voiced support for redefining it. The Chairs polled the WG on the Question: "open discussion on repurposing acronym?" With the clarifying question - change acronym or redefine meaning? Chairs: keep ‘moq’ change what it stands for.
Poll: open discussion on repurposing acronym? Yes 7, No 21, No opinion 8
Chairs closed the poll and asked that any additional input to be sent to the mailing list.
Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-moq-interop-at-ietf-123-00
Mike English presented the Interop report.
Alan Frindell asked if it would help to do things differently - This
time the interopt target draft was published 4 weeks before interopt
time. Was that the right amount of time? Question for the room. Some
think it was good and one knew what to expect. Some wanted a bit more
time especially as -12 had so much changes. -12 was also difficult to
read.
The plan for the Interop in Toronto is -14 which should be published
end of august. Draft -15 before the meeting.
Which lead to the question is there a benefit in having -15? Which was
answered if it clarifies errors or issue detected with the interop
target.
It was noted that a number of draft changes are waiting for ALPN. Do
we know when that will resolve or should we just accept that we will
have two versions that are unable to interop? Alan noted that we
just needs one browser that support ALPN in WebTransport and we can
progress. It was noted that Victor was working on it but it have not
shipped yet.
draft: https://datatracker.ietf.org/doc/draft-ietf-moq-warp/
slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-warp-update-v1-00
Will Law (Akamai) lead the discussion after having noted some PRs that
been merged, and a new PR proposing an field for "isComplete".
How to seperate the parts: custom, first path maps to connection or
use ‘!’ as delimiter. Mike English noted that some mapping is
required. Ted Hardie noted why don’t use url templates (RFC 6570 -
https://datatracker.ietf.org/doc/rfc6570/).
Can we specify auth tokens in both path and query? Mike: prefers
bearer token than including it in the path. Alan Frindell commented
that he would like to have clarification on the expected interaction
between outside of MOQT and what goes into MOQT. Who is expceted to
take a token from the URL and put it inot MOQT requests? Cullen
Jennings: can't slam urls into one. disagree that this is the
solution. This is all part of discovery which is bigger topic we need
to talk about. Rohan Mahy had privacy concerns with single web token.
Will: Standard bearer tokens for access control in addition to any part deal
Please review the issues and PR discussion.
Draft: https://datatracker.ietf.org/doc/draft-law-moq-cat4moqt/
Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-cat-4-moqt-v1-00
Will Law presented that they have added action limits allowing control
over what the endpoint with the token is allowed to do, like publish
or only subscribe and fetch.
Tokens are expected to have a long life time, there are a lot of
requests in MOQT sessions so how often do the server evaluate claims?
Propsal is to add a re-evaluate property that tells the server the maximum
length between evaluation of the token.
Richard Barnes asked is it not sufficient with Expires? Will answered
that the usage is different. Expiry indicates when it can't be used
any longer, and do not force re-evaluation, only reneval of the token
itself. Also the timeframes for re-evaluation and reneval can be very
different.
The question here is what types of matching operators do we need? Do
we really need contain, as we anyway will match each tuple in the
namespace + track hierarchy down to the included level for prefix.
Will we encoded something on the end of the namespace so we need
suffix? The second question is if prefix only matches whole tuples.
Suhas thinks there are motivation for all, and that the implementation
burden of these four are reasonable and ensure future freedom. On the
question of whole tuple matching he noted this issue also in MOQT and
there exist an issue for the question.
Harald asked how big will these tokens be? Likely up to a couple of
kilobytes.
Alan noted that in MOQT currently is is vague, but the plan is to
match whole tuple fields, we don't do partial field match due to
performance implications. But don't let what is being done in MOQT
constrain this.
Cullen commented that with the many tuples in the namespace
it is easy to create boundaries needed by the application. However,
at the same time one could allow partial field matches also. With
the token being used in the control plane only there is less performance
concerns over a somewhat more costly matching.
Mo commented that he is glad that it was pointed out that WARP will
constrain the name spaces to use UTF-8 or something filed values. Are
you also constraining how concatination and the delimiter will work.
Will conclude that this is currently underspecified in WARP and will
addressed to something that is URI safe.
Skipped, welcome comment on how to map for the appropriate action.
Call to action : request adoption by moq wg
Poll: Should the WG adopt this document as WG item? Yes 18 No 0 No Opinion 8
Chairs: Will confirm adoption on the mailing list.
Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-moqt-issues-for-madrid-02
Alan Frindell Presentsed how we are currently doing in general with
Issues. PR #1016 is coming with a new varint format used in this
draft. But that can't land until ALPN as it will brake SETUP
negotiation.
Currently an every verb has error code. What is mandetory for a relay
to implement? What is mandatory for a publisher to implement? Need
both PUBLISH and SUBSCRIBE?
Ian noted that we could just skip "not supported" and see what the
issues are. Alan noted that ignoring requests are not great, the
sender wants a response. What is really needed to be supported. Ian
thinks with the exception of Announce most of the other things. Alan
noted that Victor had field and issue related to what do a Smart-TV
need to support that only wants to do subscribe.
Mike Enlish stated he prefers to keep "not supported" for now. Stuff
not implemented yet, would like field practice and handle what is not
implemented by getting the "not supported". When we are ready for WG
last call we can consider to remove it. Alan noted should relays be
required to support all? Mike uncertain at this point.
Mo we need to make it clear what is mandatory with relays? Thinks
everything should be mandatory for relays as otherwise how would the
application handle unsupported features in the relay. Applications
wont support somehting outside of application need. We should remove
language about pub/sub in general and be clear on the actual roles,
relays or original publishers and end consumer.
Cullen stated that relays have to implenent all the stuff in the base
draft. Need to define specification for end goal, not intermediate
development. Applications are free to not implement all. If relays
must implement everything, and then provide them a way to report
errors when they don’t, this will be a disaster. Alan noted that
we use the same set of message for relays and there are nuances
that needs to be handled with the relays and other endpoints.
Victor commented currently we define draft around reading everything
and understanding everything. Fear is that client only implements sub
someone tried to send pub, it explodes. Does relay implementing all
and keeping not supported is sufficient? Unclear but there are other
ways of rejecting a request.
Zahed Sarker: Relays should support everything. But for gradual
deployment relay using not supported could be a good thing. Alan
notes that if we go with requirement that relay must support
everything, then we dont need to do feature discovery.
Tiani Jiang: We already have case of more than one relay on the
node. That will handle multiple applications. Not supporting everying
in the relay would case issues.
Conclusion: will write proposal - conclusion ok to have relay support all the verbs
Are we ok with two differnt ways to encode “no objects”? Or should we only a single method?
Cullen states returning a 0 length stream is better and easier to
implement. Reduces two differnt paths to code to one path to
code. Empty response stream is better approach. Suhas supported also empty response stream.
Will disagrees absence of something indicator state is dangerous. The
sender could have issues with sending it. Alan notes that FETCH is
full of this design patter. Not dying on this hill.
Mo comments it is important to support upstream fetch, allow for
optimization. Likes to have both.
Summary: Unclear conclusions. Please commment on the issue. Try to make a fact based decision.
Ian thinks we meant should and didn't tell you which case it
is. Proposed that oen indicates when doing announce and the publisher
have all the stuff, or when announce and only have partial
information. Alan noted that there are also the fully redundnat
video ingest. This would require a new indicator in the publish
or subscribe_ok
Cullen commented that he is interested to see Ian's proposal. We mean
MUST, and should phrase this another way because there was quality of
implementation issues or handling error cases when.
Suhas originally raised this issue. Thinks it is MUST, and without
additional mechanism the relay have to send to everything.
Victor thinks there are multiple issues with text. This protocol was
originally designed with the assumprtion that there would only a
single publisher. The many publisher to many subscribers is a much
harder. This is not a SHOULD or MUST, this is in generally a bad idea.
Alan asked about the make before break being the reason is that okay.
This will likely require overlap in subscriptions, but the publisher
only publish ones. Victor clearly objects to cases where a subet of
objects are published to one relay and another subset to another relay
over the same time period.
Mo we are looking at this from different use cases. Doesnt make sense
to talk unless we talk about all use cases. Lets start with active +
passive standyby where the passive will only be actived if the
previous active fails. For this use case the current text kind of
work. When it comes to active-active redundancy where both publish all
of the objects this text doesn't work. For multi-publisher where they
publish disjunct object sets it would not work. And for the case of
a publisher lossing connection and reconnecting it would also not work
as one would wait on a timeout. Harald comments that for the
standby case in a real-time use case one do need to have subscriptions to
both relays as one don't have time to establish that when one fails.
Martin Duke this text is meaningless if you dont require the
subscription to have forwarding one. Cullen commented that text that
is needed is that only edge relays that could avoid using Forward=1 as
it can know that only a single.
Cullen commented that lets not discuss again the existance of this
use case.
Conclusion: May examine Ians idea. Many want MUST. Victor wants MUST
NOT. Chairs concluded seems like we currently have use case that
doesnt work without MUST. Either use Ians solution or go to MUST.
Alan: Will make the PR to say MUST. Look into proposal
Rohan: Issues with scheduling. Came to this session for a discussion
that was moved to Tuesday with no warning. Please be mindful of that
in the future.
Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-moq-abr-in-moq-00
Ian Swett presenting that there are already a number of issue
field. But the track switching between different bit-rate
representation should work assuming their duration boundardies are
aligned. The more challenging issues is around finding the bit-rate
that is supported.
Cullen asked are we doing this at the right layer. Wouldn't QUIC layer
be the better layer to discover more bandwidth for example using
retransmissions or FEC. Should we request the QUIC WG to provide such
a mechanism. Mo commented that transport needs input to be able to
work efficiently. This including API to indicate both that the
application is application limited and what would be the next bit-rate
layer. Cisco has also expermineted with having the highets priorty
very low-bitrate data being sent immediately bypassing the congestion
controller.
Will commented that Akamai and bytedance are going to collab on a
draft on how to send network level information to help starting up the
connection and might also help with the ABR steps. So if you are attempting
to invent something here please talk to us.
Alan noted that if we need API to transport we also will need it from
WebTransport. Webtransport are trying to conclude and they have
standardized APIs so we need to ask quickly if we it.
Ian further talked about the issues with filling up the congestion
window when probing or sending low priorty data. Zahed Sarker
commented that he thinks it is not a good idea to say anything on the
moq transport about the congestion window, instead just provide a
priorty queue. Ian noted that it will not work for WebTransport. Zahed
may need to have solution for webtransport, not for everything.
Suhas, we did experiments on realy bad WIFI with the audio. A
potential solution might be to have a track, provide some extra info
to relay would be a good idea so the relay can trigger a probe up.
Ian summarizing lets explore if we can have a feature probing with
duplicates, and if we can perform better prioritizing.
Server side ABR challenges. We have longstanding github issue, may now be
achievable. Do we want a ‘publish timestamp’ object extension to keep
tracks in sync?
Mo and Will hade some discussion on this aspect. Thinks it will
require a more heawy weight mechanism than what is currently in
MOQT. Should have a proposal written up before September Interim
meeting.
Alan looks like this would need some new additional feature in the
relay. Would they be possible to add as an extension to MOQT. Ian
thinks it would. This would really only be needed by the relay facing
the consuming endpoints. The bitrate needs to go somewhere in the catalog
or somewhere else.
Will Law expanding on the idea Mo brought up. Plan to introduce some
custom forwarding filters. Instead of expressing just forward or not,
indicate forward the one with a bit-rate provided by the publisher.
Cullen likes the proposals. It would be great to focus the functionality
to edge relays. However, it looks like we will have some information that
will need to be forwarded by all relays. Ian agreed that something would
be useful, like average bit-rate of the track above.
Ian there is a need to keep subscribed in sync. Warp suggests groups
IDs but do the WG thinks that is sufficient or should we have
something more. Alan commented that it would be interesting to have an
extension. The relays can't make assumptions about group ID structure
so an extension could ensure behavior.
Mo there was a list discussion this week. When it comes to timestamps will
we need multiple timestamps and which will be accessible to the relay.
Conclusion: Ian to summarize discussion and keeping on discussing in the issues.