Re: [AVT] New Version Notification for draft-peilin-avt-rtp-burst-01

[Ye-Kui Wang <yekuiwang at huawei.com>]

You got the context of the example correctly. 

> - RS knows when to terminate the burst, so it will eventually 
> stop regardless.

Are you saying that, the RS will termniate the onging burst if it receives a
new RMS-R requesting a new burst?

BR, YK 

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com] 
> Sent: Thursday, March 12, 2009 1:32 PM
> To: Ye-Kui Wang; Colin Perkins; Peilin YANG
> Cc: IETF AVT WG
> Subject: RE: [AVT] New Version Notification for 
> draft-peilin-avt-rtp-burst-01
> 
> > Ali,
> > 
> > I agree that your draft has much better considerations in these 
> > aspects, which are very good. However, I think there are still some 
> > holes to be filled.
> > 
> > One example. The RR has sent an RTCP BYE for the unicast burst, and 
> > then sent an RMS-R to request changing to another channel. However, 
> > due to whatever reason, the RS has not received the RTCP BYE but 
> > received the RMS-R. What does the RS do? Where is this specified in 
> > the draft?
> 
> BYEs are not reliable as it is the case in any RTP 
> application. So, I believe you are asking what will happen to 
> the burst when the client is not interested in the burst any 
> more and sends BYE to RS to stop the burst but BYE gets lost: 
> There are two cases:
> - A new BYE can also be sent when the timing rules allow for it.
> - RS knows when to terminate the burst, so it will eventually 
> stop regardless.
> 
> HTH,
> -acbegen
>  
> > BR, YK
> > 
> > > -----Original Message-----
> > > From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> > > Sent: Thursday, March 12, 2009 12:51 PM
> > > To: Ye-Kui Wang; Colin Perkins; Peilin YANG
> > > Cc: IETF AVT WG
> > > Subject: RE: [AVT] New Version Notification for
> > > draft-peilin-avt-rtp-burst-01
> > > 
> > > In our approach, we are trying to make the system work 
> even when the 
> > > control messages get lost. The re-ordering is also dealt with as 
> > > much as possible.
> > > 
> > > Please refer to section 5 in our draft:
> > > http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchroniz
> > > ation-for-rtp-02#page-9
> > > 
> > > BR,
> > > -acbegen
> > > 
> > > > -----Original Message-----
> > > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> > > Behalf Of
> > > > Ye-Kui Wang
> > > > Sent: Thursday, March 12, 2009 9:34 AM
> > > > To: 'Colin Perkins'; 'Peilin YANG'
> > > > Cc: 'IETF AVT WG'
> > > > Subject: Re: [AVT] New Version Notification for
> > > > draft-peilin-avt-rtp-burst-01
> > > > 
> > > > 
> > > > I guess the authors have not done such an analysis, and 
> I think I 
> > > > share Colin's understanding that the two (probably implicit) 
> > > > assumptions are there, based on my understanding of them.
> > To avoid
> > > > being based on the first assumption, an (almost) exhaustive
> > > analysis
> > > > of all possible exceptional cases regarding the loss or
> > > out-of-order
> > > > delivery of RTCP messages that would affect the control
> > > message state
> > > > synchronisation. I guess the second is related to the 
> first, e.g. 
> > > > regarding that the issues of loss or out-of-order delivery
> > > may remain
> > > > even some solutions have been taken.
> > > > 
> > > > On the other hand, I think these issues apply to
> > > > draft-versteeg-avt-rapid-synchronization-for-rtp-02 as 
> well, and 
> > > > should be studied in the same context, e.g. through the 
> potential 
> > > > design team that may be created. I will try to have a related 
> > > > discussion to the list soon in a separate thread.
> > > > 
> > > > BR, YK
> > > > 
> > > > > -----Original Message-----
> > > > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]
> > > On Behalf
> > > > > Of Colin Perkins
> > > > > Sent: Tuesday, March 10, 2009 7:20 PM
> > > > > To: Peilin YANG
> > > > > Cc: IETF AVT WG
> > > > > Subject: Re: [AVT] New Version Notification for
> > > > > draft-peilin-avt-rtp-burst-01
> > > > > 
> > > > > On 8 Mar 2009, at 06:08, Peilin YANG wrote:
> > > > > > This is the version 01 for draft-peilin-avt-rtp-burst-01.
> > > > > > The major change compared to version 00 adds some
> > > descrptions for
> > > > > > exception handling, and redefines some fields of
> > > feedback message.
> > > > > > Welcome any comments.
> > > > > >
> > > > > > http://tools.ietf.org/id/draft-peilin-avt-rtp-burst-01.txt
> > > > > 
> > > > > Have you done any analysis of how the mechanisms
> > defined in this
> > > > > draft relate to the guidelines in draft-ietf-avt-rtcp- 
> > > > > guidelines-01.txt? There seem to be assumptions of
> > reliable state
> > > > > synchronisation for the control messages, and about the
> > > behaviour of
> > > > > the underlying network, that aren't necessarily warranted.
> > > > > 
> > > > > --
> > > > > Colin Perkins
> > > > > http://csperkins.org/
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > 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
> > > > 
> > > 
> > 
> > 
> > 
>