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

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

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?

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