I'm sorry we didn't find time to hear your talk about Flexicast in the
IETF meeting, so I thought I would send a few comments to encourage you!
I do like the idea of re-using the MP mechanisms to add a multicast
context, that seems interesting.
I'd be happy to comment and contribute to this - if this is further
developed, so please don't take the "picky" comments about the use of
keywords in the wrong way, they were intended to help me think more...
/The frame also contains the
first packet number that the receiver MAY receive with this key./
- Seems love an odd may is this a “can”?
- or needs to explicitly say what a receive does with lower numbered
packets.
/After receiving an FC_ANNOUNCE frame
advertising a flexicast flow, a receiver SHOULD decide to join it./
- seems an odd requirement, I’d have expected MAY here?
/The Flexicast QUIC source SHOULD NOT consider the receiver as an
active member of the flexicast flow before it has received an
FC_STATE with the LISTEN action from the receiver./
- Seems like not quite useful text, can you perhaps describe what the
sender is required to do?
/ In parallel of sending the FC_STATE frame with the JOIN action, the
receiver MUST notify the underlying routing network its willingness
to receive packets from the flexicast flow. /
- This seems like you expect a join request towards the source, which
I’d expect is an IGMP/MLD message, although I am not quite sure what you
intended? (This seems to be better expressed in the next sentence.
/However, receivers SHOULD only leave a flexicast
flow only if network conditions are not met to ensure a good quality
of experience for the applications. /
- This seems odd, why is this necessary, and why do we need RFC 2119
language here? I expected receives ought to be allowed to leave (albeit
with some expected performance reduction).
/Upon reception of this frame, the Flexicast QUIC
source MUST NOT consider anymore the receiver as a member of the
flexicast flow, /
- This might be better as a MUST remove from the set of receivers?
/The receiver SHOULD drop any path
state for the flexicast flow regarding this flexicast flow. /
- Why SHOULD when it erases the path info, is this not MUST?
/ The
source SHOULD decide to remove the receiver from the flexicast flow
and continue receiving data through unicast, even temporarilly. /
- I am unsure why this is SHOULD, I’;d have expected MAY - with advice
about when this is expected to be beneficial.
/Receivers MUST NOT send MP_ACK on the flexicast flow
since this path is unidirectional./
- Well yes, but I’d say this was more “cannot” because the path is
unidirectional.
/A Flexicast QUIC source must
wait for the acknowledgment from all receivers listening to the
flexicast flow before releasing state for the transmitted data./
- Aha this is where the multicast design needs to consider what two do.
I wonder if it is wise to set a timeout to receive the ACKs. If a
receiver fails to ACK in time, and continues to fail, that could be a
threshold that causes the sender to expel the receiver from the group
(as you suggest)?
Lastly, I think we've learned a lot of the years how to make multicast
work effectively and so I do think some form of congestion control is
important to require (and specify), so this part of the I-D will be
useful to develop.
Re-key might be needed if we wish to constrain the multicast delivery
tree to authorised receivers - both because a shared group key can be
re-shared with receivers outside the group, and because if someone
leaves or is evicted, they ought to loose their access to the key.
However, this all seems achievable because we have the unicast context
from QUIC also to use to synchronise any key update.
It do think it's also important to find controls to protect the
multicast infrastrcuture from abuse - and I expect we can do this, since
we have a control channel, by specifying a way to evict poorly perfoming
or malicious receivers from the group.
Happy to talk and look forward to the next revision!
Best wishes,
Gorry
