[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

Yes, your understanding is corrrect. That is my meaning.

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!
 *****************************************************************************************

----- 原邮件 -----
发件人: Zou ZiXuan <tendyntu at huawei.com>
日期: 星期四, 四月 2日, 2009 下午7:55
主题: RE: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow
收件人: 'Peilin YANG' <yangpeilin at huawei.com>, 'David R Oran' <oran at cisco.com>, "'Bill Ver Steeg (versteb)'" <versteb at cisco.com>, Tom.Van_Caenegem at alcatel-lucent.be, 'Zeev Vax' <zeevvax at microsoft.com>
抄送: avt at ietf.org

> > 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
> 
>