[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for the same unicast flow
I am leaving all but the last comment from Dave for Bill.
> > 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.
This relates to the discussion about loss of RMS-I message during Bill's
presentation in San Francisco. My understanding then and also now is as
follows. If during the burst, the burst bitrate is changed by the RS due to
whatever reason, and the RS has not sent an RMS-I or the sent RMS-I was
lost, it should not be a disater to the client as it knows the its buffer
status, and it can also know the change of the burst bitrate and even the
value of the changed burst bitrate if it wants. So why there is a problem
here?
BR, YK
> -----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
>