[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] New Version Notification for draft-peilin-avt-rtp-burst-01
Let me try this (putting you as the first in the To field) by simply
Replying to All.
BR, YK
> -----Original Message-----
> From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com]
> Sent: Thursday, March 12, 2009 2:14 PM
> To: Ye-Kui Wang; IETF AVT WG
> Subject: RE: [AVT] New Version Notification for
> draft-peilin-avt-rtp-burst-01
>
> YK-
>
> I seem to get your emails OK at my Cisco account. Perhaps it
> is Ali and not all of Cisco :-)
>
> bvs
>
> -----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 2:05 PM
> To: 'IETF AVT WG'
> Subject: Re: [AVT] New Version Notification for
> draft-peilin-avt-rtp-burst-01
>
>
> Resending, as Ali seems cannot receive the email if his email
> address is the first in the To field. And more remarkably, it
> seems that Cisco email servers rejects to deliver emails
> directly from Huawei email servers :-(
>
> Sorry for spamming others.
>
> BR, YK
>
> > -----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 1:43 PM
> > To: 'Ali C. Begen (abegen)'; 'Colin Perkins'; 'Peilin YANG'
> > Cc: 'IETF AVT WG'
> > Subject: Re: [AVT] New Version Notification for
> > draft-peilin-avt-rtp-burst-01
> >
> >
> > 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
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> > _______________________________________________
> > 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
>