-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
Behalf Of David R Oran
Sent: Wednesday, April 01, 2009 9:02 PM
To: Bill Ver Steeg (versteb)
Cc: Tom.Van_Caenegem at alcatel-lucent.be; avt at ietf.org; Zeev Vax
Subject: Re: [AVT] Rapid Acquisition of Multicast Streams
(RAMS) - multipleRAMS-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
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt