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

[Zou ZiXuan <tendyntu at huawei.com>]

Hi, David

> But how do you know? Even the same FT address for two 
> channels could be different boxes.

In this case, from RR's sight, it is the same FT for different channels.
Which box take response to RR's control message (BYE or RMS-R) is
decided by FT. So RMS-R with the semantics of ceasing all the RTP and
RTCP streams of the current channel does not have any problem of use in
this case. 

For different FT context, there also exist a possible case where BYE is
not used: If a FT-a does not have the channel that RMS-R requests to
change to, the FT-a can redirect the RMS-R and RR to the right FT-b, and
at the same time, FT-a ends the unicast/retransmission RTP/RTCP stream. 

I have a question, what if the uncast/retransmission session can be
reused for different channel? Is BYE necessary in this case?

 > But the standard should be specified for the general case, 
> no? It really doesn't save much if anything by trying to 
> avoid sending the BYE, does it? Or am I missing some 
> optimization in the single box case that is a clear win?

I have no objection on your point that the standard should be specified
for the general case, given that we are developing a standard works in a
"bandwidth restricted" circumstance, which should avoid the collision
between the "reference information" of new channel and stream of current
channel. Because If "reference information" get lost due to collision
cause by control message get lost or out-of-order, the rapid sync may
fail.   So, I think the problem of control message (i.e. BYE/RMS-T) get
lost or out-of-order also should be taken into account in the standard.
And we are trying to give a solution for the problem.

> -----Original Message-----
> From: David R Oran [mailto:oran at cisco.com] 
> Sent: Monday, March 16, 2009 10:23 PM
> To: Zou ZiXuan
> Cc: 'Ali C. Begen (abegen)'; 'Ye-Kui Wang'; 'Bill Ver Steeg 
> (versteb)'; 'Colin Perkins'; 'Peilin YANG'; 'IETF AVT WG'
> Subject: Re: [AVT] New Version Notification for 
> draft-peilin-avt-rtp-burst-01
> 
> 
> On Mar 16, 2009, at 5:47 AM, Zou ZiXuan wrote:
> 
> > Hi, Ali,
> >     	
> >> 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.
> >>
> > ZX: BYE is a measure for ending the unicast RTP session, 
> but may not 
> > be mandatory.
> >
> > Here is an example of ending the current session and 
> starting a new on 
> > in the channel change context without using BYE message, as follows:
> > 	1, Every channel has a SDP which includes the descriptions of 
> > Sessions for e.g. unicast and retransmission, such as:
> > 	m=video 40000 RTP/AVPF 96
> >      	i=Primary Source Stream #1
> >    	..
> >
> >    	m=video 40002 RTP/AVPF 97
> >      	i=Unicast Retransmission Stream #1
> > 	..
> >
> >
> >  	2, a) When RR and RS start up (or power on), RS creates all the 
> > sessions involved in SDP
> What if there is a lineup with 5000 channels? This seems 
> highly unrealistic for state consumption on the RR, not to 
> mention the potential problems with holding a session open on 
> a multicast group you have not joined. What use is such state?
> 
> > 	     b) RR creates session using SDP and sends RMS-R;
> >           	     c) Upon receiving RMS-R, RS creates or updates the 
> > state of relevant sessions and issue RMS-I and burst.
> > 	     d) When RR changes channel again, it selects the 
> SDP for the new 
> > channel, deletes the previous session, creates the new session and 
> > sends RMS-R:
> Uh, I don't think that works. You can't just "delete the 
> previous session" if it's the retransmission session because 
> that leaves state hanging on the RS. You do really need to 
> send a BYE to the RS so it knows when to clean up; otherwise 
> it will keep sending you sender reports, if nothing else. If 
> you're talking about the multicast session, it's still a good 
> idea to send a BYE in order for the SSM DS to keep 
> approximate track of the number of receivers for RTCP timer 
> tuning and other functions.
> 
> > 	     e) Upon receiving the new RMS-R, RS updates the state of 
> > relevant sessions according to RR's SSRC, ceases the 
> previous burst as 
> > well as retransmission and start a new sync process.
> >
> I think you are still missing the fact that it can't do this, 
> because the RS for one channel may be a totally different box 
> from the RS for another channel.
> 
> > As you mentioned before, this is the example of same FT for the 
> > previous and the new channel. In different FTs case, BYE 
> can be used 
> > for RR indicating its leaving the old FT.
> >
> But how do you know? Even the same FT address for two 
> channels could be different boxes.
> 
> >>> 	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?
> > RS may know about this by
> >
> > ZX: ZX: I'm trying to answer this by the example given as above.
> >
> Right. I don't think your example works correctly.
> 
> >>
> >>> 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.
> >
> > ZX: I'm trying to answer this by the example given as above.
> >>
> >>> 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.
> > ZX: What measures do we have?
> > We think giving RMS-R the ability of ceasing the old burst and 
> > retransmission is a measure in case of switching channel under the 
> > same FT, and as the above example shows, the session can be 
> > ended/updated without using BYE.
> >
> But the standard should be specified for the general case, 
> no? It really doesn't save much if anything by trying to 
> avoid sending the BYE, does it? Or am I missing some 
> optimization in the single box case that is a clear win?
> 
> >> 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.
> >
> > ZX: The issue of leave lost is not a similar problem. RMS-R request 
> > for "reference information" coming in the first place in 
> burst. So it 
> > is much likely that the reference information get lost so that fast 
> > sync fails, which is supposed to be avoid during sync.
> Sorry, I'm not following this. The problem is congesting the 
> channel due to either multiple multicast flows OR multiple 
> unicast bursts for different channels going on at the same 
> time, right? So, wheheter the phenomenon that causes 
> congestion is not terminating an earlier burst for channel 1 
> in order to burst for channel 2, or failing to stop a 
> multicast stream for channel 1 (due to a lost IGMP LEAVE) in 
> order to join multicast channel 2 the results are the same.
> 
> > Unlike RMS-R, IGMP
> > join does not request for "reference information" and thus does not 
> > lead to the lose of reference information. On the other hand, IGMP 
> > join/ leave never take the bandwidth restriction into account ever 
> > since it was created. But this problem should be considered during 
> > fast sync.
> I'm sorry - I really can't follow what you're saying here. 
> Could you try again?
> 
> Thanks, DaveO.
> 
> 
> >
> >> -acbegen
>