[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow
On Apr 1, 2009, at 7:52 PM, Bill Ver Steeg (versteb) wrote:
When we added the ability to send more than one RAMS-R message, we
opened up a few design points that we now need to consider.
We need to have some nomenclature for describing the "initial RMS-R"
and "subsequent RMS-R", so I will start with using those words.
Better words would be appreciated.
The first design point I would like to address is what the RS is
required to do when it receives an RAMS-R for a burst that is
already in flow (aka "subsequent RMS-R"). We stated that the least
it could do was "ignore it". Does this imply that there is no
requirement to send an RMS-I in response to RMS-R messages
referencing an in-progress flow?
No. In order to have rational state machines the RS MUST reply to each
RAMS-R with a RAMS-I. Whether there is a "Reference to the in-progress
flow" is a secondary issue. The key point is that semantically the
RAMS-I returned in response to a RAMS-R can be (from a state machine
point of view) no different from the first, because either the RS may
never have received the first RAMS-R, or conversely the RAMS-I sent in
response to te earlier RAMS-R might have been lost.
This is how protocols utilizing idempotency semantics have to operate.
If so, we should add clarifying text in the document that cautions
the RR not to assume the RAMS-R was dropped.
Well, "caution" is not the term I would use. Just show the state
machines and the whole thins should be obvious (at least it would be
to me).
I briefly considered requiring the RS to send a RAMS-I for each
received RAMS-R. Unfortunately, this then leads to another set of
corner cases, and may result in a chatty exchange of messages.
Uh, I don't think so. The only time a message other than the two
needed to initiate a burst is sent is if a message is lost. Worst case
this is one extra message - if the sequence is RAMS-R->RAMS-
I(lost)...RAMS-R(retry)->RAMS-I.
As long as none of the fields in the messages have themselves non-
idempotent semantics (e.g. by being deltas rather than absolute
values) I fail to see what corner cases arise.
We also need to consider how to deterministically differentiate
between the initial RMS-R message and subsequent RMS-R messages,
particularly in the event of packet loss or (unlikely) re-ordering.
I would argue that we in fact don't need to do this as long as we wait
long enough for retransmission to avoid delayed duplicates or messages
crossing on the wire. If that is that is the case I would much prefer
that we use transaction ids instead of or in addition to sequence
numbers. But I think neither is in fact necessary
In low-probability case the RAMS-R messages permute, the client can
always recover by sending another RAMS-R with the burst rate it wants.
What this does point out however, is that we should have either
DIFFERENT fields for the values in the RAMS-I that are meant to echo/
confirm values requested by the RAMS-R, versus those set unilaterally
by the server, or use a DIFFERENT message type for a unilateral RAMs-
(something other than -I) generate by the RS that was not triggered by
receipt of a RAMS-R.
Either would work.
This probably leads us to including a monotonically increasing
sequence number on the RMS-R.
This begs the question of who throws away state when. For example, if
I try to do a RAMS on multicast group 1, give up, try to do a RAMS on
multicast group 2, give up, and then try to do a RAMS on group 1
again. What sequence number does the last of these RAMS-R message
have? Why would it be different than if I never had done the RAMS-R on
flow 2? How can the RS possibly know which case obtains?
I think we're actually making the protocol much more complicated and
with more error states by introducing sequencing to avoid the problems
that would arise from permuted messages on a retransmission time-out.
It's just so much easier to ensure all the protocol semantics are
idempotent.
Dropped RMS-R messages should not be a protocol problem, as the
first one received will trigger the burst. Subsequent RMS-R messages
either change the burst shape or they do not, and they do not
trigger additional messages.
Really? Not if they have sequence numbers and the RS failed to forget
the state of an earlier burst.
Similarly, if the initial RMS-I is dropped it will probably trigger
an additional RMS-R message. Subsequent RMS-I messages will either
be received by the RR or they will not, and they will not trigger
additional messages.
So, has anybody considered these design points in detail?
Yes. Not for RAMS, but for numerous other request/response protocols
that operate idempotently.
I have started to go down this path, but it gets complicated quickly.
So you're discovering :-)
In order to limit the complexity, I suggest that we state that the
first received RMS-R triggers a RMS-I. Further RMS-R messages may
flow. Further RMS-I messages may also flow, but there is no explicit
requirement to send an RMS-I in response to a subsequent RMS-R.
No, this is a bug. It never allows the client to ascertain the state
of the server.
DaveO.
Bill VerSteeg
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt