Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow

[Zou ZiXuan <tendyntu at huawei.com>]

> The RS shall reply to each RAMS-R fom the viewpoint of state
> machine.Nevertheless,
> subsequent RAMS-I messages is not trigged by reception of RAMS-R
> messages,
[ZiXuan] If subsequent RAM-I message is not triggered by reception of
RAMS-R, then why do we need a DIFFERENT field in the RAMS-I message? I
guess you meant those RAMS-I messages generated unilaterally by RS, is
my understanding correct?
> so I also think that adding a DIFFERENT field for the values in the
RAMS-I
> should be a good choice.
> In the meantime this can avoid having a seqnum on 2 of the 3 messages.
> 
> Regards,
> 
> Peilin
> 
>
************************************************************************
************
> ******
>  This email and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address
is
> listed above. Any use of the information contained here in any way
(including,
> but not limited to, total or partial disclosure, reproduction, or
dissemination)
> by persons other than the intended recipient(s) is prohibited. If you
receive
> this email in error, please notify the sender by phone or email
>  immediately and delete it!
> 
>
************************************************************************
************
> *****
> 
> ----- 原邮件 -----
> 发件人: David R Oran <oran at cisco.com>
> 日期: 星期四, 四月 2日, 2009 上午9:02
> 主题: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) -
multiple
> RAMS-R messages for the same unicast flow
> 收件人: "Bill Ver Steeg (versteb)" <versteb at cisco.com>
> 抄送: Tom.Van_Caenegem at alcatel-lucent.be, avt at ietf.org, Zeev Vax
> <zeevvax at microsoft.com>
> 
> >
> > 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
> >
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt