[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

To: "Zou ZiXuan" <tendyntu at huawei.com>, "Ye-Kui Wang" <yekuiwang at huawei.com>, "Bill Ver Steeg (versteb)" <versteb at cisco.com>, "Colin Perkins" <csp at csperkins.org>, "Peilin YANG" <yangpeilin at huawei.com>
Subject: Re: [AVT] New Version Notification for draft-peilin-avt-rtp-burst-01
From: "Ali C. Begen (abegen)" <abegen at cisco.com>
Date: Fri, 13 Mar 2009 08:59:57 -0700
Authentication-results: sj-dkim-3; header.From=abegen at cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: IETF AVT WG <avt at ietf.org>
Delivered-to: avt at core3.amsl.com
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=12721; t=1236960007; x=1237824007; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen at cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20<abegen at cisco. com> |Subject:=20RE=3A=20[AVT]=20New=20Version=20Notification=20 for=20draft-peilin-avt-rtp-burst-01 |Sender:=20; bh=CWU8qYtHtnBJtt6/RqUBVvbM1IMvAMafV8FwFzhu1+A=; b=QQ2WgP/daF+MUloFvuYyOlWmyI5k7yNe8LTxvhfHWupDVR6bXq/fPy922y s+qzozizjr16hIEtpjILxClsfaxNgeYo1+strexJqvA6k3Exnn99Ovy8Dv99 kawenwP1bm;
In-reply-to: <000001c9a3c2$c4836c60$0102a8c0 at china.huawei.com>
List-archive: <http://www.ietf.org/mail-archive/web/avt>
List-help: <mailto:avt-request@ietf.org?subject=help>
List-id: Audio/Video Transport Working Group <avt.ietf.org>
List-post: <mailto:avt@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
References: <04CAD96D4C5A3D48B1919248A8FE0D5408DC4E05 at xmb-sjc-215.amer.cisco.com> <000001c9a3c2$c4836c60$0102a8c0 at china.huawei.com>
Thread-index: Acmh1wa/BpSyLqkJTn6Jofy1N+DhDABVps3gAAEkHvAAAN5zkAAAdf1wAACZCgAACURwUAAEYTEgAAWVMcAAGsrwMA==
Thread-topic: [AVT] New Version Notification for draft-peilin-avt-rtp-burst-01

Hi Zou,

> Hi, All :)
>     I'm Zou ZiXuan, Yekui's colleague and the co-editor of peilin's
> draft. I'd like to join the discussion on the draft :)
> See my comments as below
> 
> > 
> > > The problem is that, if the unwanted burst and the newly 
> requested 
> > > burst are flowing at the same time, congestion will 
> likely happen, 
> > > therefore, handling of such two streams independently does 
> > not seems 
> > > very good.
> > > On the other
> > > hand, if the new burst has to start after the 
> retransmitted BYE is 
> > > received or a timeout on the RS has reached, additional 
> tunning-in 
> > > delay is introduced, which is obviously bad for the whole purose.
> > 
> > You send the BYE, and then an RMS-R for the new stream. 
> > Unless BYE gets lost or is processed later the RMS-R, the new 
> > burst will not collide with the old burst.
> > 
> > The FTs for the current stream and the new stream might be 
> > different. But, what you are saying below assumes they are 
> > all on the same FT address/port.
> > 
> > -acbegen
> 
> Before talking about different FTs,  I'll draw attention from this
> complexity back
> to some points for a while that I think should be clarified 
> at the first
> place: 
> 	1) There is semantic confusion among RMS-T and BYE in the draft,
> which I think should be further clairfied: RMS-T
> is used for ceasing the unicast burst with its seq field being empty
> when RR only receive unicast burst during fast sync. BYE is also

The seqnum field in the RMS-T may or may not be filled depending on whether RR has already received the first packet or not.

> mandated to do the SAME THING in case of
> unicast burst and multicast stream co-existing if RR are no long
> interested in the current channel.  So why not use RMS-T for both of
> these cases for achieving the same purpose, otherwise it would be very
> confused.

BYE (on the retransmission/burst session) ends the unicast RTP session. RMS-T ends (or intends to end) the burst, not the session. The session stays available for (potential) outstanding retransmissions.

> 	2) In the draft, BYE message also terminates the current
> retransmission session in the second case. This operation may be
> redundant, because retransmission operation is only driven by the
> request issued by RR - that is, leaving the current multiast session
> naturally drive the current retransmission operation to terminate. On

If RR leaves the current mcast session, how is RS supposed to know about this?

> the other hand, the retransmission session can be terminated by
> out-of-bound measure, for example SDP. So we think using BYE 

How? Here, we are following rules of 3550.

> message is
> not a must in this context.
>            	4) So we suggested that, For semantic clarity in the
> draft,  a)  RMS-T should be used for ceasing the burst in 
> both cases. b)
> BYE message may be not a necesisty.

See the BYE related section of RFC 3550.
 
> Now for Begn's question on different FTs,   what we are 
> proposing below
> does assume the streams are all on the same FT address/port.  But this
> is one of the possible case of deployment where what we are proposing
> works for the issue of out-of-order or message lose. And In case of
> different FTs, upon receiving the RMS-R, the FT for the new stream can
> simply ignore RMS-R's request of ceasing the burst as it is 
> not provided
> by the FT. The RMS-T message in this case can be sent to the 
> FT for the
> current stream to stop the burst. 

The scheme should allow different FTs for different streams as well. None of the RTCP messages are reliable and they may get lost but we do have measures against the loss of such control messages.

FYI, IGMP join/leave messages are not reliable, either. If "leave" gets lost and the burst starts, it is a similar problem. I believe we all should do our best in developing the control plane GIVEN the protocol requirements.

-acbegen
 
> In fact, the problem  of out-of-order or lose also applys to 
> the case of
> different FTs. The problem seems to be more likely to occur 
> as compared
> to that in case of the same FT. This is a interesting topic. 
>  
> 
> 
> > > Therefore, the RS should terminate the ongoing burst upon 
> > receiving of 
> > > a new RMS-R message requesting a burst for another channel.
> > > 
> > > BR, YK
> > > 
> > > > -----Original Message-----
> > > > From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com]
> > > > Sent: Thursday, March 12, 2009 2:12 PM
> > > > To: Ali C. Begen (abegen); Ye-Kui Wang; Colin Perkins; 
> Peilin YANG
> > > > Cc: IETF AVT WG
> > > > Subject: RE: [AVT] New Version Notification for
> > > > draft-peilin-avt-rtp-burst-01
> > > > 
> > > > As seen from the RS, it is also possible that the RR is 
> actually 
> > > > requesting acceleration on more than one stream, so the 
> RS should 
> > > > handle the two flows independently. The new stream should 
> > start, and 
> > > > the old stream should be handled independently of the 
> new stream, 
> > > > each channel having its own FT address and port.
> > > > 
> > > > As Ali states, the old stream will be terminated by 
> > another BYE sent 
> > > > from the RR or by a timeout on the RS.
> > > > 
> > > > This discussion does bring up the point of concurrent sessions 
> > > > between a sender and a receiver. We need to clarify the 
> > definition 
> > > > of RR and RS.
> > > > In some contexts, they refer to an "instance of a state 
> > machine on a 
> > > > device" and in some cases they refer to the device itself. Some 
> > > > sections of the draft (particularly step
> > > > 7 of section 6.2) imply that there is only one stream at a time 
> > > > between any two devices. We will clarify in the next draft.
> > > > 
> > > > Bvs
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] 
> > On Behalf 
> > > > Of Ali C. Begen (abegen)
> > > > 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
> 
>

Follow-Ups:
- Re: [AVT] New Version Notification for draft-peilin-avt-rtp-burst-01
  - From: Zou ZiXuan

References:
- Re: [AVT] New Version Notification for draft-peilin-avt-rtp-burst-01
  - From: Ali C. Begen (abegen)
- Re: [AVT] New Version Notification for draft-peilin-avt-rtp-burst-01
  - From: Zou ZiXuan

Prev by Date: Re: [AVT] Review of draft-versteeg-avt-rapid-synchronization-for-rtp-02
Next by Date: Re: [AVT] Review of draft-versteeg-avt-rapid-synchronization-for-rtp-02
Previous by thread: Re: [AVT] New Version Notification for draft-peilin-avt-rtp-burst-01
Next by thread: Re: [AVT] New Version Notification for draft-peilin-avt-rtp-burst-01
Index(es):
- Date
- Thread