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

From: Peilin YANG <[email-masked]>
Date: Sun, 08 Mar 2009 14:08:02 +0800

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

Regards,
Peilin

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

---

From: Colin Perkins <[email-masked]>
Date: Tue, 10 Mar 2009 23:19:56 +0000

On 8 Mar 2009, at 06:08, Peilin YANG wrote:
> The major change compared to version 00 adds some descrptions for  
> exception handling, and redefines some fields of feedback message.
> Welcome any comments.
>

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/

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 12 Mar 2009 12:33:45 -0400

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: [email-masked] [mailto:[email-masked]] 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
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 12 Mar 2009 09:50:52 -0700

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-synchronization-for-rtp-02#page-9 

BR,
-acbegen

> Behalf Of Ye-Kui Wang
> Sent: Thursday, March 12, 2009 9:34 AM
> To: 'Colin Perkins'; 'Peilin YANG'
> Cc: 'IETF AVT WG'

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 12 Mar 2009 13:21:10 -0400

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 

> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> 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 
> 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.
> 
> Behalf Of 
> > Ye-Kui Wang
> > 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.
> > 
> > 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
> > 
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of Colin Perkins

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 12 Mar 2009 10:31:55 -0700

> 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

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 12 Mar 2009 13:42:35 -0400

You got the context of the example correctly. 

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

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

BR, YK 

> Sent: Thursday, March 12, 2009 1:32 PM
> > 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:
> > > 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.
> > > 
> > > > > Audio/Video Transport Working Group [email-masked]

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 12 Mar 2009 14:05:00 -0400

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

> Sent: Thursday, March 12, 2009 1:43 PM
> To: 'Ali C. Begen (abegen)'; 'Colin Perkins'; 'Peilin YANG'
> Cc: 'IETF AVT WG'
> Are you saying that, the RS will termniate the onging burst 
> if it receives a new RMS-R requesting a new burst?
> 
> BR, YK 
> 
> 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:

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 12 Mar 2009 14:12:01 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)

> received the RMS-R. What does the RS do? Where is this specified in 

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
 
> > In our approach, we are trying to make the system work even when the

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 12 Mar 2009 14:13:57 -0400

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: [email-masked] [mailto:[email-masked]] 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 :-( 

BR, YK

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

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 12 Mar 2009 14:21:22 -0400

Let me try this (putting you as the first in the To field) by simply
Replying to All. 

BR, YK 

> From: Bill Ver Steeg (versteb) [mailto:[email-masked]] 
> Sent: Thursday, March 12, 2009 2:14 PM
> To: Ye-Kui Wang; IETF AVT WG
> I seem to get your emails OK at my Cisco account. Perhaps it 
> is Ali and not all of Cisco :-) 
> 
> bvs 
> 
> 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 :-( 
>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 12 Mar 2009 14:43:27 -0400

I got your email, so email connectivity seems to be as it should (at
least right now).

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ye-Kui Wang
Sent: Thursday, March 12, 2009 2:21 PM
To: Bill Ver Steeg (versteb); 'IETF AVT WG'
Subject: Re: [AVT] New Version Notification for
draft-peilin-avt-rtp-burst-01

BR, YK 

> I seem to get your emails OK at my Cisco account. Perhaps it is Ali 
> and not all of Cisco :-)
> 
> bvs
> 
> 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

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 12 Mar 2009 18:31:48 -0400

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. 

Therefore, the RS should terminate the ongoing burst upon receiving of a new
RMS-R message requesting a burst for another channel. 

BR, YK 

> Sent: Thursday, March 12, 2009 2:12 PM
> To: Ali C. Begen (abegen); Ye-Kui Wang; Colin Perkins; Peilin YANG
> Cc: IETF AVT WG
> 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
> 
> 
> Behalf Of Ali C. Begen (abegen)

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 12 Mar 2009 17:17:22 -0700

> 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

---

From: Zou ZiXuan <[email-masked]>
Date: Fri, 13 Mar 2009 18:02:06 +0800

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

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. 

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
> > 
> > > 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.
> > > 
> > > 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.
> 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
> > > 
> > > 
> > > Of Ali C. Begen (abegen)
> 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:

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 13 Mar 2009 08:59:57 -0700

Hi Zou,

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

> these cases for achieving the same purpose, otherwise it would be very

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.

> naturally drive the current retransmission operation to terminate. On

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

> out-of-bound measure, for example SDP. So we think using BYE 

How? Here, we are following rules of 3550.

> message is

See the BYE related section of RFC 3550.
 
> 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
 
> actually

---

From: Zou ZiXuan <[email-masked]>
Date: Mon, 16 Mar 2009 17:47:04 +0800

Hi, Ali,
     	
> > draft. I'd like to join the discussion on the draft :) See 
> my comments 
> > as below
> > 
> > > 
> > > Unless BYE gets lost or is processed later the RMS-R, the 
> new burst 
> > > will not collide with the old burst.
> > > 
> > > different. But, what you are saying below assumes they are all on 
> > > the same FT address/port.
> > > 
> > > -acbegen
> > 
> > complexity back to some points for a while that I think should be 
> > clarified at the first
> > place: 
> > 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
	     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:
	     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.

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. 

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

ZX: ZX: I'm trying to answer this by the example given as above.

> How? Here, we are following rules of 3550.

ZX: I'm trying to answer this by the example given as above.
> > draft,  a)  RMS-T should be used for ceasing the burst in 
> both cases. 
> > b) BYE message may be not a necesisty.
> 
> > 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.

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

> -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.
> >  
> > 
> > 
> sessions 
> > > > > > > > assumptions are there, based on my 
> understanding of them.
> > > > > > To avoid
> > > > > > > > > synchronisation for the control messages, and 
> about the
> > > > > > > behaviour of

---

From: David R Oran <[email-masked]>
Date: Mon, 16 Mar 2009 10:23:16 -0400

>  	2, a) When RR and RS start up (or power on), RS creates all the
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?

> the new channel, deletes the previous session, creates the new session
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.

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

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

> ZX: ZX: I'm trying to answer this by the example given as above.
Right. I don't think your example works correctly.

> FT, and as the above example shows, the session can be ended/updated
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?

> 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
I'm sorry - I really can't follow what you're saying here. Could you  
try again?

Thanks, DaveO.

---

From: Zou ZiXuan <[email-masked]>
Date: Wed, 18 Mar 2009 17:35:43 +0800

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.

> From: David R Oran [mailto:[email-masked]] 
> 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'
> depending on 
> >> whether RR has already received the first packet or not.
> >>
> >> 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.
> >
> 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?
> 
> > 	     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 
> 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.
> 
> > 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.
> 
> >> 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.
> > 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
>