Subject: [AVT] Response codes for RAMS

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 11 Sep 2009 12:29:59 -0700

Here is some input for the response codes for the RAMS-I message. We have a 16-bit field to carry these. Some of these codes are also planned to be used in the RAMS XR messages. We are planning to use http-style codes.

By no means, this is a complete list. We probably should not be having a code for anything that can go wrong on the server side, but at the same time differentiation among some of the key states on the server side may be quite useful for RR.

Note that these codes will be maintained by IANA in a registry and when/if new extensions are provided for RAMS, they can register new codes.

Comments, suggestions are welcome. 

-acbegen

1xx Informational

	RAMS was terminated by RAMS-T
	RAMS was terminated by BYE
	--> These two are probably useful when/if RS wants to ack RR-driven terminations
	RAMS was terminated by RS
	Parameter update (bitrate, join time, etc.)

2xx Success

	RAMS Request accepted
	RAMS Burst completed

3xx Redirection

	Any code here?

4xx Client Error

	Invalid RAMS Request
	Invalid min/max buffer requirement in RAMS-R
	Invalid max bw requirement in RAMS-R

5xx Server Error

	No bandwidth available
	No CPU available
	Other RS internal errors
	RAMS is disabled on RS
	RAMS is not available for this RR
	RAMS is not available for the requested multicast stream
	No valid starting point is available for the requested multicast stream
	No reference information is available for the requested multicast stream

6xx Global Failure

	Do we have any for this category?

---

From: Jinwei Xia <[email-masked]>
Date: Mon, 14 Sep 2009 10:03:00 +0800

Hi Ali,

Well done, this is an detailed list beyond my expectation. Majority are
reasonable and I only have a couple of comments. 

The "RAMS was terminated by RS" code definition is vague, can you elaborate
it? IMHO its rule overlap with items in 5xx Server Error because it can be
triggered by any one item in 5xx Server Error.

The "Invalid RAMS Request" code definition is comprehensive, it can be cause
by missing PID, mismatch PID or some other reasons. Should we take these
into account? But if you regard any violation in RTCP feedback header is in
scope of "Invalid RAMS Request" code definition, it is aslo acceptable for
me :-)

However I have not any idea about redirection scenario too. Hope someone can
complement it.

BR
Jinwei

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ali C. Begen (abegen)
> Sent: Saturday, September 12, 2009 3:30 AM
> To: [email-masked]
> Subject: [AVT] Response codes for RAMS
> 
> Here is some input for the response codes for the RAMS-I 
> message. We have a 16-bit field to carry these. Some of these 
> codes are also planned to be used in the RAMS XR messages. We 
> are planning to use http-style codes.
> 
> By no means, this is a complete list. We probably should not 
> be having a code for anything that can go wrong on the server 
> side, but at the same time differentiation among some of the 
> key states on the server side may be quite useful for RR.
> 
> Note that these codes will be maintained by IANA in a 
> registry and when/if new extensions are provided for RAMS, 
> they can register new codes.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Tue, 15 Sep 2009 17:48:22 +0200

Ali,
See inline my comments,
Tom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: vrijdag 11 september 2009 21:30
To: [email-masked]
Subject: [AVT] Response codes for RAMS

Here is some input for the response codes for the RAMS-I message. We
have a 16-bit field to carry these. Some of these codes are also planned
to be used in the RAMS XR messages. We are planning to use http-style
codes.

By no means, this is a complete list. We probably should not be having a
code for anything that can go wrong on the server side, but at the same
time differentiation among some of the key states on the server side may
be quite useful for RR.

Note that these codes will be maintained by IANA in a registry and
when/if new extensions are provided for RAMS, they can register new
codes.

-acbegen

1xx Informational

Tom:  'RAMS" is not defined, do you mean "burst" or "retransmission
session"?  I assume the former?

Tom: again "RAMS" is not clear. In this case however, a bye sent by the
receiver will terminate the retransmission session, and in that case the
RAMS-I (carrying the response code) should not be sent anymore by the
RS. Hence I do not really see the need for this error code.

	--> These two are probably useful when/if RS wants to ack
RR-driven terminations

Tom: RAMS == "burst"?

2xx Success

	RAMS Request accepted
	RAMS Burst completed

Tom: is this to be sent in a dedicated RAMS I message. I do not think it
can be combined with the field "join MC time" in the same RAMS-I message

3xx Redirection

	Any code here?

Tom: I like this one, but it is complicated. To be meaningful, we should
define a field that provides the new location /transport address of the
(new) RS server. However, there is interference with the RSI messages
defined in rtcp-ssm: a dedicated RSI message is defined transported over
ssm that provides a (new) address for the FB target. Since the RS
includes the FT entity, this is a conflict situation.

4xx Client Error

	Invalid RAMS Request

5xx Server Error

	No bandwidth available
	No CPU available
	Other RS internal errors

Tom: would call this "unspecified RS internal error"

	RAMS is disabled on RS
	RAMS is not available for this RR
	RAMS is not available for the requested multicast stream
	No valid starting point is available for the requested multicast
stream
	No reference information is available for the requested
multicast stream

6xx Global Failure

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 15 Sep 2009 10:20:22 -0700

> From: Jinwei Xia [mailto:[email-masked]]
> Sent: Sunday, September 13, 2009 10:03 PM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: RE: [AVT] Response codes for RAMS
> 
> Hi Ali,
> 

We can come up with better expressions for these. These are informational and I am not sure whether we will need them. My goal (particularly in the first two) was that we could use these in case RS wanted to let RR know why the RAMS process was terminated or ACK the RR-driven terminations. I believe the first one could be used but the second one is probably useless as RR will not be waiting for any more packets in the ret. session after sending BYE.

> by missing PID, mismatch PID or some other reasons. Should we take these

We don't request PID. In RAMS request, we can only ask to acquire a multicast stream, not a PID. Invalid RAMS request means that the RAMS-R message was not formatted properly.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 15 Sep 2009 10:25:31 -0700

> session"?  I assume the former?

I meant "RAMS process." We could use "burst" but we might need to think more about this to come up with a better expression here.
 
> RS. Hence I do not really see the need for this error code.

Right, this is useless.
 
> can be combined with the field "join MC time" in the same RAMS-I message

Could be. But, that does not conflict with anything, right?
 
> includes the FT entity, this is a conflict situation.

We might skip 3xx.
 
> Tom: would call this "unspecified RS internal error"

Sure.

-acbegen

---

From: zouzixuan <[email-masked]>
Date: Fri, 18 Sep 2009 16:56:58 +0800

Hi, All
	We suggest to add a response code in "Success" category as "RAMS
Request Accepted but only preamble/reference information available". This
response code would be chosen when RS detects that the bandwidth is scarce
for serving the RR with the unicast burst, where while RR is capable of
parsing the preamble/reference information as specified in
"draft-begen-avt-rtp-mpeg2ts-preamble-02.txt". Right after the RAMS-I with
this response code, the preamble/reference information of the source stream
would be sent from RS to the RR. After which, RR may join the multicast at
an appropriate time. The preamble/reference information is used for rapidly
processing the source stream received in the current multicast session at
RR.
	
Best regards,
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: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C.
Begen (abegen)
Sent: Saturday, September 12, 2009 3:30 AM
To: [email-masked]
Subject: [AVT] Response codes for RAMS

Here is some input for the response codes for the RAMS-I message. We have a
16-bit field to carry these. Some of these codes are also planned to be used
in the RAMS XR messages. We are planning to use http-style codes.

By no means, this is a complete list. We probably should not be having a
code for anything that can go wrong on the server side, but at the same time
differentiation among some of the key states on the server side may be quite
useful for RR.

Note that these codes will be maintained by IANA in a registry and when/if
new extensions are provided for RAMS, they can register new codes.

-acbegen

1xx Informational

	--> These two are probably useful when/if RS wants to ack RR-driven
terminations

2xx Success

	RAMS Request accepted
	RAMS Burst completed

3xx Redirection

	Any code here?

4xx Client Error

	Invalid RAMS Request

5xx Server Error

	No bandwidth available
	No CPU available
	Other RS internal errors
	RAMS is disabled on RS
	RAMS is not available for this RR
	RAMS is not available for the requested multicast stream
	No valid starting point is available for the requested multicast
stream
	No reference information is available for the requested multicast
stream

6xx Global Failure

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 18 Sep 2009 11:44:52 +0200

Hi Zouzixuan,

IMO, this can be hardly called a success, as the RS does not do what is
the core of the RAMS draft: sourcing an RTP burst from its cache
containing data as received from the ssm. Such a response with only
preamble information is not what was requested by the RAMS-R. Note that
preamble information can be seen as an optional feature that leverages
RAMS, but is not part of RAMS.

I am not convinced we can just add such a mode of operation to RAMS.
Questions popping up:
-the preamble information may be associated with (older) data that is
cached, hence brings no value to a RR that gets this information which
cannot be used for processing the "fresh" data received in the ssm.
Worse..it may even provide wrong information.
-an RR may not be interested in just receiving the preamble data, and
prefers to just join the ssm asap. Or may not even understand it. How to
handle this? 
-does the interaction still require a RAMS-T, when the RS just sends the
preamble data?
-at what bitrate should the RR expect the data (MUST be signaled in
RAMS-I!). This is important for the RR to know, in terms of when it can
safely join the ssm.
-..

Kind Regards,
Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
zouzixuan
Sent: vrijdag 18 september 2009 10:57
To: 'Ali C. Begen (abegen)'; [email-masked]
Subject: Re: [AVT] Response codes for RAMS

Hi, All
	We suggest to add a response code in "Success" category as "RAMS
Request Accepted but only preamble/reference information available".
This response code would be chosen when RS detects that the bandwidth is
scarce for serving the RR with the unicast burst, where while RR is
capable of parsing the preamble/reference information as specified in
"draft-begen-avt-rtp-mpeg2ts-preamble-02.txt". Right after the RAMS-I
with this response code, the preamble/reference information of the
source stream would be sent from RS to the RR. After which, RR may join
the multicast at an appropriate time. The preamble/reference information
is used for rapidly processing the source stream received in the current
multicast session at RR.
	
Best regards,

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

-acbegen

1xx Informational

2xx Success

	RAMS Request accepted
	RAMS Burst completed

3xx Redirection

	Any code here?

4xx Client Error

	Invalid RAMS Request

5xx Server Error

	No bandwidth available
	No CPU available
	Other RS internal errors
	RAMS is disabled on RS

6xx Global Failure

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 18 Sep 2009 16:42:43 -0400

On first examination, I agree with Tom on this one. It is not clear that
a preamble is useful in the absence of the burst. We could try to run
down all of the corner cases this would introduce, but this does not
appear to be an attractive path. We always need to trade off complexity
against features, and this does not look promising.

If there were a clear motivating case to entice us to go down this path,
I could be convinced otherwise.........

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
VAN CAENEGEM Tom
Sent: Friday, September 18, 2009 5:45 AM
To: zouzixuan; Ali C. Begen (abegen); [email-masked]
Subject: Re: [AVT] Response codes for RAMS

Hi Zouzixuan,

Kind Regards,
Tom

-----Original Message-----

Hi, All
	
Best regards,

-----Original Message-----

-acbegen

1xx Informational

2xx Success

	RAMS Request accepted
	RAMS Burst completed

3xx Redirection

	Any code here?

4xx Client Error

	Invalid RAMS Request

5xx Server Error

	No bandwidth available
	No CPU available
	Other RS internal errors
	RAMS is disabled on RS

6xx Global Failure

---

From: zouzixuan <[email-masked]>
Date: Sat, 19 Sep 2009 14:03:04 +0800

Hi, Tom
	Thank you for your comments. Inline.

Best regards,

> From: VAN CAENEGEM Tom [mailto:[email-masked]]
> Sent: Friday, September 18, 2009 5:45 PM
> IMO, this can be hardly called a success,
Well, yes, it might be not that appropriate to call this a success. It might
be discussed later, after we clarify your following comments.
-zou

 as the RS does not do what is
> RAMS, but is not part of RAMS.

We did mean to propose it as an optional feature for RAMS. In case of short
of bandwidth, RS could reject RAMS request, or respond with this for the
purpose of rapid acquisition, of which the importance for RAMS is mentioned
couple of times through the RAMS draft. It is optional, but is actually very
important regarding RAMS, see the comments of Eric Friedrich:

> > >  As the preamble draft describes, decoders require such 
> > > information as the PAT, PMT, PCR, and any ECMs (see Slide 3 in
> > > http://www.ietf.org/proceedings/75/slides/avt-9.pdf)
> > >   before they can begin decoding the RAMS burst and I-Frame.
> > > Rarely is this information directly adjacent in the stream.
> > > In most cases, the decoder must wait for all of the above
> elements
> > > to occur naturally before beginning the decoding.
> > > Depending on the stream this can take several hundred
> milliseconds
> > > of extra channel change time.

-zou

> Worse..it may even provide wrong information.

If we talk about the preamble information format based on Cisco's draft, we
see very low probability that preamble be overdue or go wrong when RR switch
the channel. I would appreciate if you can show a typical case where this
happen vey likely:)
-zou

> prefers to just join the ssm asap. Or may not even understand it. How to
If RR is not willing/capable to handle the preamble, then may just join the
ssm right away. 
-zou
> -does the interaction still require a RAMS-T, when the RS just sends the
RAMS-T would be sent after preamble is received. Before RS gets RAM-T, it
may keep updating the preamble if necessary (if it see changes in preamble,
though in my understanding, the probably is low)
-zou

> RAMS-I!). This is important for the RR to know, in terms of when it can
The bitrate does not matter much. The preamble would fill up only 1 or 2
packets, depending on the packet size. RS can send the preamble at a burst
rate as is signaled in RAM-I. RR join the multicast right after receiving
the preamble. 
-zou