Subject: Re: [AVT] Open issues in the RAMS draft

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 3 Sep 2009 12:53:44 -0700

Yes by server I mean RS (retransmission server). 

Rams-r does not provide such info, correct. RS can decide whether a new tsrap point will soon show up on multicast based on the previous observations. But don't miss the important point here. For mpeg2-ts there are no such magical tsrap points. The tsrap data will be dispersed over mutiple ts packets.  Thus bursting + preamble info will (almost always) provide the fastest acquisition.   

-acbegen

----- Original Message -----
From: Jinwei Xia <[email-masked]>
To: 'Martin Ellis' <[email-masked]>
Cc: Ali C. Begen (abegen); [email-masked] <[email-masked]>
Sent: Thu Sep 03 04:38:44 2009
Subject: RE: [AVT] Open issues in the RAMS draft

Hi Martin,

Yes, I have reviewed this portion in RAMS draft.  The rejection use case
maybe caused by lacking RAMS authorization on RR, or by absence burst stream
on SR, or some other reason. But what's I wonder is another use case,
please check the below bullet, I copy from last mail.

>> In theory, if the current point in multicast transmission is very 
>> close to a TSRAP point, server can ask the receiver to join the 
>> multicast right away (rather than starting a burst).

If the "server" is RS, I agree that receiver can be indirectly asked to join
multicast upon receiving rejection message from RS. However, how did RS
learn the current point is adjacent to TSRAP? RAMS-R does not provide such
information. 

Anyway, your response partly answers my question. Thank you!  :-)

BR

Jinwei

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Martin Ellis
> Sent: Thursday, September 03, 2009 6:21 PM
> To: Jinwei Xia
> Cc: Ali C. Begen (abegen); [email-masked]
> Subject: Re: [AVT] Open issues in the RAMS draft
> 
> Hi,
> 
> Wouldn't this just be RS rejecting the RAMS request (via a 
> RAMS-I message)?
> 
> From Section 6.2, step 2:
>        If RS cannot provide a rapid acquisition service, RS 
> rejects the
>        request and informs RR immediately via an RAMS-I 
> message.  If RR
>        receives a message indicating that its rapid 
> acquisition request
>        has been denied, it abandons the rapid acquisition attempt and
>        MAY immediately join the multicast session by sending an SFGMP
>        Join message towards its upstream multicast router for the new
>        primary multicast session.
> 
> 
> Martin
> 
> 2009/9/3 Jinwei Xia <[email-masked]>:
> > Hi Ali,
> >
> > Sorry to pick up this thread again, however I am not 
> concern whether 
> > one method overwhelm another, but just hope some questions can be 
> > clarified in belowing description.
> >
> >>
> >> I am not saying RAMS is worse, I am saying RAMS is better.
> >> Dedicating the resources to the unicast burst initially and then 
> >> switching to multicast will perform faster acquisition.
> >> In theory, if the current point in multicast transmission is very 
> >> close to a TSRAP point, server can ask the receiver to join the 
> >> multicast right away (rather than starting a burst).
> >
> > what's the specific message sent from server to receiver? This 
> > specific message is spontaneous or is triggered by 
> receiver? And the 
> > "server" is multicast source, RS or some entity else?
> >
> >> This is, what I said, available in our draft.
> >
> > Does above description is embodied in RAMS draft? Which section?
> >
> > Your prompt feedback is very appreciated :-)  Thank you!
> >
> > BR
> >
> > Jinwei
> >
> > We can work out
> >> the math in the next meeting if you like.
> >>
> >> One point worth to consider in practice is that in mpeg2-ts video, 
> >> there won't be many "magical" tsrap points (from where you 
> can start 
> >> decoding immediately). Simply starting from an I frame 
> does not cut 
> >> it (as explained in our other draft).
> >> Many other components are required by the decoder, so, 
> almost always 
> >> starting a unicast burst will perform better since the 
> unicast burst 
> >> will provide exactly that information to the receiver in 
> the shortest 
> >> amount of time.
> >>
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
> >

---

From: Jinwei Xia <[email-masked]>
Date: Fri, 04 Sep 2009 10:02:08 +0800

Hi Ali,
 
Thank your clarification, I have not reviewed mpeg2ts-preamble draft and I
will check it later, but I admit bursting is an very efficient acquisition
approach.

BR
Jinwei

  _____  

From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Friday, September 04, 2009 3:54 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [AVT] Open issues in the RAMS draft

Rams-r does not provide such info, correct. RS can decide whether a new
tsrap point will soon show up on multicast based on the previous
observations. But don't miss the important point here. For mpeg2-ts there
are no such magical tsrap points. The tsrap data will be dispersed over
mutiple ts packets.  Thus bursting + preamble info will (almost always)
provide the fastest acquisition.  

-acbegen

----- Original Message -----
From: Jinwei Xia <[email-masked]>
To: 'Martin Ellis' <[email-masked]>
Cc: Ali C. Begen (abegen); [email-masked] <[email-masked]>
Sent: Thu Sep 03 04:38:44 2009
Subject: RE: [AVT] Open issues in the RAMS draft

Hi Martin,

BR

Jinwei

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 4 Sep 2009 10:01:35 -0400

This thread brings up an important point about RAMS. I thought it was
clear in the document, but perhaps it merits an explicit sentence or
two. 
 
It is important to note that the RS may determine that no burst should
be sent to the RR, and the RR should not make any inferences as to why.
It may be due to system state (no multicast flow present at the RS, no
network resources available, no RS CPU resources available, etc) or due
to the real-time status of the flows (a burst may not provide
significant acceleration for a given simple flow at a given point in
time, so it may be omitted). In any case, the RR should locally decide
whether to abandon the flow or join the flow. Once the RS sends the
negative RAMS-I, the RR behavior is a decision point local to the RR.
 
bvs

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jinwei Xia
Sent: Thursday, September 03, 2009 10:02 PM
To: Ali C. Begen (abegen); [email-masked]
Cc: [email-masked]
Subject: Re: [AVT] Open issues in the RAMS draft

Hi Ali,
 
Thank your clarification, I have not reviewed mpeg2ts-preamble draft and
I will check it later, but I admit bursting is an very efficient
acquisition approach.

BR
Jinwei

________________________________

	
	Rams-r does not provide such info, correct. RS can decide
whether a new tsrap point will soon show up on multicast based on the
previous observations. But don't miss the important point here. For
mpeg2-ts there are no such magical tsrap points. The tsrap data will be
dispersed over mutiple ts packets.  Thus bursting + preamble info will
(almost always) provide the fastest acquisition.  
	
	-acbegen
	
	----- Original Message -----
	From: Jinwei Xia <[email-masked]>
	To: 'Martin Ellis' <[email-masked]>
	Cc: Ali C. Begen (abegen); [email-masked] <[email-masked]>
	Sent: Thu Sep 03 04:38:44 2009
	Subject: RE: [AVT] Open issues in the RAMS draft
	
	Hi Martin,
	
	Yes, I have reviewed this portion in RAMS draft.  The rejection
use case
	maybe caused by lacking RAMS authorization on RR, or by absence
burst stream
	on SR, or some other reason. But what's I wonder is another use
case,
	please check the below bullet, I copy from last mail.
	
	>> multicast right away (rather than starting a burst).
	
	If the "server" is RS, I agree that receiver can be indirectly
asked to join
	multicast upon receiving rejection message from RS. However, how
did RS
	learn the current point is adjacent to TSRAP? RAMS-R does not
provide such
	information.
	
	Anyway, your response partly answers my question. Thank you!
:-)
	
	BR
	
	Jinwei

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 4 Sep 2009 07:07:17 -0700

> From: Bill Ver Steeg (versteb)
> Sent: Friday, September 04, 2009 5:02 PM
> To: Jinwei Xia; Ali C. Begen (abegen); [email-masked]
> Cc: [email-masked]
> This thread brings up an important point about RAMS. I thought it was clear in the
> document, but perhaps it merits an explicit sentence or two.
> 
> It is important to note that the RS may determine that no burst should be sent to the RR,
> and the RR should not make any inferences as to why. It may be due to system state (no

Yes. There could be many reasons. The Response code field in the RAMS-I message should be sufficient in terms of providing a reason to RR, though.

> multicast flow present at the RS, no network resources available, no RS CPU resources
> available, etc) or due to the real-time status of the flows (a burst may not provide
> significant acceleration for a given simple flow at a given point in time, so it may be
> omitted). In any case, the RR should locally decide whether to abandon the flow or join
> the flow. Once the RS sends the negative RAMS-I, the RR behavior is a decision point local
> to the RR.

Yes, RS does not tell what RR should be doing.

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jinwei Xia
> Thank your clarification, I have not reviewed mpeg2ts-preamble draft and I will check it
> later, but I admit bursting is an very efficient acquisition approach.
> 
> 
> BR
> Jinwei
> 
> 
> 	Rams-r does not provide such info, correct. RS can decide whether a new tsrap point
> will soon show up on multicast based on the previous observations. But don't miss the
> important point here. For mpeg2-ts there are no such magical tsrap points. The tsrap data
> will be dispersed over mutiple ts packets.  Thus bursting + preamble info will (almost
> always) provide the fastest acquisition.
> 
> 	-acbegen
>

---

From: Jinwei Xia <[email-masked]>
Date: Mon, 07 Sep 2009 12:00:07 +0800

Hi Ali and Bill,

I have some questions, please see more comments inline.

> > clear in the document, but perhaps it merits an explicit 
> sentence or two.
> > 
> > be sent to the RR, and the RR should not make any inferences as to 
> > why. It may be due to system state (no
> 
> Yes. There could be many reasons. The Response code field in 
> the RAMS-I message should be sufficient in terms of providing 
> a reason to RR, though.

IMHO it makes sense to enum Response code field value to reflect the status
of RAMS-I.  

> 
> > multicast flow present at the RS, no network resources 
> available, no 
> > RS CPU resources available, etc) or due to the real-time 
> status of the 
> > flows (a burst may not provide significant acceleration for a given 
> > simple flow at a given point in time, so it may be omitted). In any 
> > case, the RR should locally decide whether to abandon the 
> flow or join 
> > the flow. Once the RS sends the negative RAMS-I, the RR 
> behavior is a decision point local to the RR.
> 

I partly agree with you. The rejection can be cause either by above listed
RS inner determination or by any reflection from RR or third party. For
example, RR is not authorize for RAMS, or the multicast flow requested by RR
is not authorized to RR, etc.  So RR has right to know why it is rejected
and log the event even if RR should locally decide whether to abandon the
flow or join the flow. Make any sense?

BR
Jinwei

> > Thank your clarification, I have not reviewed 
> mpeg2ts-preamble draft 
> > and I will check it later, but I admit bursting is an very 
> efficient acquisition approach.
> > 
> > 
> > BR
> > Jinwei
> > 
> > 
> > 	Rams-r does not provide such info, correct. RS can 
> decide whether a 
> > new tsrap point will soon show up on multicast based on the 
> previous 
> > observations. But don't miss the important point here. For mpeg2-ts 
> > there are no such magical tsrap points. The tsrap data will be

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 7 Sep 2009 02:49:14 -0700

> From: Jinwei Xia [mailto:[email-masked]]
> Sent: Monday, September 07, 2009 12:00 AM
> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); [email-masked]
> Cc: [email-masked]

Sure, we will provide a list of response codes hopefully in the next revision. We will post a draft to the list. 

> flow or join the flow. Make any sense?

Sure, I am not sure how detailed the response codes should be. A message like "Service not available" could cover all the cases mentioned above and many others. Should we consolidate scenarios and produce common response codes or should we itemize them in detail? Input is welcome from everyone.

-acbegen

---

From: zouzixuan 61302 <[email-masked]>
Date: Tue, 08 Sep 2009 00:22:36 +0800

> > To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); 
> [email-masked]> Cc: [email-masked]
> Sure, we will provide a list of response codes hopefully in the 
> next revision. We will post a draft to the list. 
> 
> > >
> > is not authorized to RR, etc.  So RR has right to know why it is 
> rejected> and log the event even if RR should locally decide 
> whether to abandon the
> Sure, I am not sure how detailed the response codes should be. A 
> message like "Service not available" could cover all the cases 
> mentioned above and many others. Should we consolidate scenarios 
> and produce common response codes or should we itemize them in 
> detail? Input is welcome from everyone.
> 
> -acbegen

For better harmonization between RR and RS in various cases, some scenarios may to some extent be itemized. And accordingly, though maybe not every response code leads to a strict requirement on what RR to do, some recommendations on RR's response would at least be there as optional elements. We'd like to contribute some ideas for this.

-zou
> > 1BR
> > 22Jinwei

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 7 Sep 2009 09:34:29 -0700

> For better harmonization between RR and RS in various cases, some scenarios may to some
> extent be itemized. And accordingly, though maybe not every response code leads to a
> strict requirement on what RR to do, some recommendations on RR's response would at least
> be there as optional elements. We'd like to contribute some ideas for this.

Do you mean recommendations for RR should be somehow indicated in the RAMS-I message or just be listed in the draft? I don't think the former is a good design choice. We can do the latter, but from RR's viewpoint, options are very limited anyway (e.g., give up and join the multicast right away or send a new RAMS request).

-acbegen

---

From: Jinwei Xia <[email-masked]>
Date: Tue, 08 Sep 2009 16:04:02 +0800

Hi Ali,

> > I partly agree with you. The rejection can be cause either by above 
> > listed RS inner determination or by any reflection from RR or third 
> > party. For example, RR is not authorize for RAMS, or the multicast 
> > flow requested by RR is not authorized to RR, etc.  So RR 
> has right to 
> > know why it is rejected and log the event even if RR should locally 
> > decide whether to abandon the flow or join the flow. Make any sense?
> 
> Sure, I am not sure how detailed the response codes should 
> be. A message like "Service not available" could cover all 
> the cases mentioned above and many others. Should we 
> consolidate scenarios and produce common response codes or 
> should we itemize them in detail? Input is welcome from everyone.
> 

If you will provide a set of reponse code values in next version, only
"Service not available" is far from enough. I list status values using
RAMS-I as below, the items Bracket by * are belong to RFC4585 scope, so I
hesitate whether include them in RAMS draft.  Any item can be modified and
complemented. From my viewpoint, a 8-bit unsigned integer field is enough
for response code.

RR_NOT_AUTHORIZED_FOR_RAMS:	IANA
	The RR is not authorized to send RAMS Request.

RR_NOT_AUTHORIZED_FOR_MEDIA_FLOW:	IANA
	The RR is not authorized to receiving this media flow.

NOT_MEDIA_FLOW_PRESENT_ON_RS:	IANA
	No media flow present on RS.

NOT_NETWORK_RESOURCE_AVAILABLE:	IANA
	No network resource available

*MISSING_PID_OPTION*:	     IANA
	Missing PID option

*MISSING_BLP_OPTION*:	     IANA
	Missing BLP option

*PID_MISMATCH*:	IANA
	Invalid RTP SN value

RAMS Request Accepted:	  0

Reason Unspecified:	 128

BR
Jinwei

---

From: Jinwei Xia <[email-masked]>
Date: Tue, 08 Sep 2009 16:20:41 +0800

Note that different response code hints different reaction on RR. For
example, RR can send a new RAMS-R upon receving MISSING_PID_OPTION, but must
not request again upon receving RR_NOT_AUTHORIZED_FOR_RAMS. Of course, the
reaction is RR implement issue based on vendor designment.

> Sent: Tuesday, September 08, 2009 4:04 PM
> To: 'Ali C. Begen (abegen)'; 'Bill Ver Steeg (versteb)'; 
> [email-masked]
> Cc: [email-masked]
> > mentioned above and many others. Should we consolidate 
> scenarios and 
> > produce common response codes or should we itemize them in detail? 
> > Input is welcome from everyone.
> > 
> 
> If you will provide a set of reponse code values in next 
> version, only "Service not available" is far from enough. I 
> list status values using RAMS-I as below, the items Bracket 
> by * are belong to RFC4585 scope, so I hesitate whether 
> include them in RAMS draft.  Any item can be modified and 
> complemented. From my viewpoint, a 8-bit unsigned integer 
> field is enough for response code.
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 8 Sep 2009 02:36:53 -0700

We are working on a draft text and code list and will provide it to the list soon. There are items in that list similar to the ones listed below. We reserved 16 bits to allow greater flexibility and the ability to use http-like response codes. 2xx, 3xx-level, etc.

-acbegen

> Sent: Tuesday, September 08, 2009 4:04 AM

---

From: zouzixuan <[email-masked]>
Date: Tue, 08 Sep 2009 19:58:02 +0800

>>Do you mean recommendations for RR should be somehow indicated in the
RAMS-I message or just be listed in the draft? I don't think the former is a
good design choice. We can do the latter, but from RR' s viewpoint, options
are very limited anyway (e.g., give up and join the multicast right away or
send a new RAMS request).

>>-acbegen
 
I mean (at least) the options on how to response should be listed for each
response code in the draft. Acting on which response option(s) is up to RR's
preference anyway. 

Zou ZiXuan, Senior Research Staff
Media & Communication Lab
HUAWEI TECHNOLOGIES CO.,LTD. 

Address: Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
Tel: +86 0755 28789364
Fax: +86 0755 28788317
E-mail: [email-masked]
www.huawei.com
----------------------------------------------------------------------------
---------------------------------------------------------
This e-mail 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 herein 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 e-mail in error, please
notify the sender by 
phone or email immediately and delete it!

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Tuesday, September 08, 2009 12:34 AM
To: zouzixuan 61302
Cc: Jinwei Xia; Bill Ver Steeg (versteb); [email-masked]; [email-masked]
Subject: RE: Re: [AVT] Open issues in the RAMS draft

> be there as optional elements. We'd like to contribute some ideas for
this.

Do you mean recommendations for RR should be somehow indicated in the RAMS-I
message or just be listed in the draft? I don't think the former is a good
design choice. We can do the latter, but from RR's viewpoint, options are
very limited anyway (e.g., give up and join the multicast right away or send
a new RAMS request).

-acbegen