Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields

From: Peilin YANG <[email-masked]>
Date: Wed, 01 Apr 2009 21:35:08 +0800

Please see inline comments,

******************************************************************************************
 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!
 *****************************************************************************************

----- 原邮件 -----
发件人: "Bill Ver Steeg (versteb)" <[email-masked]>
日期: 星期三, 四月 1日, 2009 上午2:46
主题: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields
收件人: [email-masked], [email-masked], [email-masked], "Ali C. Begen (abegen)" <[email-masked]>

> 
> One of the primary action items arising from the review of the Rapid
> Acquisition of Multicast Streams  draft is to identify which 
> fields are
> mandatory (and thus fixed format) and which fields are optional (and
> thus TLV format). Here is my take on the matter. Once we reach
> consensus, I will update the draft.
> 
> I have also included a description of the requested "motivating text"
> for the fields that do not already have such text in the document.
> Please let me know if I am on the right track.
> 
> There is currently no version number in the messages. Ali and I do not
> think that this is a problem because we can add new TLVs as 
> needed. I
> want to be sure we intentionally decide on this point rather than back
> into it accidently. Any comments?
> 
> We have 3 messages - 
> 
> RAMS-Request
> Max Receive BitRate - mandatory
> Min Buffer Fill Requirement - optional ( Add wording - The 
> receiver may
> have knowledge of it's buffering requirements. These requirements 
> may be
> application or device specific. For instance, the receiver may 
> need to
> have a certain amount of data in it's application buffer to handle
> interdependency within the data. If the RS knows the buffering ability
> of the receiver, it may more precisely tailor the burst to the client.
> The methods used by the receiver to determine this value is 
> applicationspecific, and thus out of scope. This mechanism can be 
> used by the
> receiver to signal the sender, if the receiver has such knowledge )
> Max Buffer Fill Requirement - optional ( Add wording - The 
> receiver may
> have knowledge of it's buffering requirements. These requirements 
> may be
> application or device specific. For instance, one receiver may 
> have more
> physical memory than another receiver, and thus can buffer more 
> data. If
> the RS knows the buffering ability of the receiver, it may more
> precisely tailor the burst to the client. The methods used by the
> receiver to determine this value is application specific, and thus out
> of scope. This mechanism can be used by the receiver to signal the
> sender, if the receiver has such knowledge )
> 
Peilin: Like Mr. Tom Taylor comment, these two optional parameters are quite clear to me. It is easier to understand and implement if there is an instance to explain it. 

> RAMS- Inform
> message Sequence Number - mandatory
> Response - mandatory, will include an enumerated list of response 
> codes- 0 is succeed, non zero is an error code. We will enumerate 
> a list of
> error codes, and note that additional error codes are possible using
> vendor-specific TLV fields. The enumerated errors will include [No
> server resources, No network resources, bad RMS-R request, WHAT
> ELSE????] 

Peilin: no buffered content. For example, when RR requests a channel,RS hasn't buffered this channel,RS will reject this request. That is to say, RR is the first receiver to request to this channel because it is impossible for RS to buffer all channels. so I think "no buffered content" is a kind of error code.

Note - we have removed the "join now semantic, as that is
> captured in the "earliest join time" field. 
> Reserved - mandatory - must be all 0s
> Max Burst Bitrate - mandatory 
> Rapid Acquisition Duration - mandatory - 0 means "join now" (Add
> wording to reflect that this is the server's current value, and 
> can be
> changed by subsequent RMS-I. Add wording to reflect that the RS can't
> consume resources forever and needs to deterministically stop the 
> flow.The RS MUST terminate the flow at this time, even if does not 
> get RMS-T
> from the RR.  ) 
> Extended RTP Sequence Number of First Burst Packet - mandatory
> Earliest IGMP Join Time - optional (we should consider making this
> mandatory in at least one RMS-I, as the client needs to eventually 
> join) 
> Rams -Terminate - 
>  Extended RTP seqnum of First Multicast packet - optional (intent 
> is to
> tell the RS the seqnum at which to stop the burst, but leave the 
> sessionopen. If the field is not present, it means "stop now")
> 
> 
> 
> Bill VerSteeg
>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 1 Apr 2009 17:37:15 -0400

Sure - hopefully this evening. Tomorrow at the latest
 
I have gotten some feedback on the included note. Once I get this text
updated and rolled into the document I will send it to you for your
updates.
 
bvs

________________________________

From: Zeev Vax [mailto:[email-masked]] 
Sent: Wednesday, April 01, 2009 1:09 PM
To: Bill Ver Steeg (versteb); [email-masked]; Ali C.
Begen (abegen)
Cc: [email-masked]
Subject: RE: Rapid Acquisition of Multicast Streams (RAMS) - Fixed and
TLV fields

Bill,

Please send me the draft for review once you are done with your
editorial path, before we send it out for review I would like to add my
changes to the draft.  

Zeev

From: Bill Ver Steeg (versteb) [mailto:[email-masked]] 
Sent: Tuesday, March 31, 2009 11:46 AM
To: [email-masked]; Zeev Vax; [email-masked]; Ali C.
Begen (abegen)
Subject: Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV
fields

Acquisition of Multicast Streams  draft is to identify which fields are

There is currently no version number in the messages. Ali and I do not
think that this is a problem because we can add new TLVs as needed. I
want to be sure we intentionally decide on this point rather than back
into it accidently. Any comments?

We have 3 messages - 

RAMS-Request

 Min Buffer Fill Requirement - optional ( Add wording - The receiver may
have knowledge of it's buffering requirements. These requirements may be
application or device specific. For instance, the receiver may need to
have a certain amount of data in it's application buffer to handle
interdependency within the data. If the RS knows the buffering ability
of the receiver, it may more precisely tailor the burst to the client.
The methods used by the receiver to determine this value is application
specific, and thus out of scope. This mechanism can be used by the
receiver to signal the sender, if the receiver has such knowledge )

 Max Buffer Fill Requirement - optional ( Add wording - The receiver may
have knowledge of it's buffering requirements. These requirements may be
application or device specific. For instance, one receiver may have more
physical memory than another receiver, and thus can buffer more data. If
the RS knows the buffering ability of the receiver, it may more
precisely tailor the burst to the client. The methods used by the
receiver to determine this value is application specific, and thus out
of scope. This mechanism can be used by the receiver to signal the
sender, if the receiver has such knowledge )

RAMS- Inform

 Response - mandatory, will include an enumerated list of response codes
- 0 is succeed, non zero is an error code. We will enumerate a list of
error codes, and note that additional error codes are possible using
vendor-specific TLV fields. The enumerated errors will include [No
server resources, No network resources, bad RMS-R request, WHAT
ELSE????] Note - we have removed the "join now semantic, as that is
captured in the "earliest join time" field. 

 Rapid Acquisition Duration - mandatory - 0 means "join now" (Add
wording to reflect that this is the server's current value, and can be
changed by subsequent RMS-I. Add wording to reflect that the RS can't
consume resources forever and needs to deterministically stop the flow.
The RS MUST terminate the flow at this time, even if does not get RMS-T
from the RR.  ) 

 Earliest IGMP Join Time - optional (we should consider making this
mandatory in at least one RMS-I, as the client needs to eventually join)

Rams -Terminate - 

  Extended RTP seqnum of First Multicast packet - optional (intent is to
tell the RS the seqnum at which to stop the burst, but leave the session
open. If the field is not present, it means "stop now")

Bill VerSteeg

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 1 Apr 2009 19:52:15 -0400

When we added the ability to send more than one RAMS-R message, we
opened up a few design points that we now need to consider.

We need to have some nomenclature for describing the "initial RMS-R" and
"subsequent RMS-R", so I will start with using those words. Better words
would be appreciated.

The first design point I would like to address is what the RS is
required to do when it receives an RAMS-R for a burst that is already in
flow (aka "subsequent RMS-R"). We stated that the least it could do was
"ignore it". Does this imply that there is no requirement to send an
RMS-I in response to RMS-R messages referencing an in-progress flow? If
so, we should add clarifying text in the document that cautions the RR
not to assume the RAMS-R was dropped. I briefly considered requiring the
RS to send a RAMS-I for each received RAMS-R. Unfortunately, this then
leads to another set of corner cases, and may result in a chatty
exchange of messages.

We also need to consider how to deterministically differentiate between
the initial RMS-R message and subsequent RMS-R messages, particularly in
the event of packet loss or (unlikely) re-ordering. This probably leads
us to including a monotonically increasing sequence number on the RMS-R.
Dropped RMS-R messages should not be a protocol problem, as the first
one received will trigger the burst. Subsequent RMS-R messages either
change the burst shape or they do not, and they do not trigger
additional messages. Similarly, if the initial RMS-I is dropped it will
probably trigger an additional RMS-R message. Subsequent RMS-I messages
will either be received by the RR or they will not, and they will not
trigger additional messages.

So, has anybody considered these design points in detail? I have started
to go down this path, but it gets complicated quickly.

In order to limit the complexity, I suggest that we state that the first
received RMS-R triggers a RMS-I. Further RMS-R messages may flow.
Further RMS-I messages may also flow, but there is no explicit
requirement to send an RMS-I in response to a subsequent RMS-R.

Bill VerSteeg

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 01 Apr 2009 20:53:10 -0400

Sending of subsequent RAMS-I messages by the RS is not trigged by reception
of RAMS-R messages, but by that the server has decided to change information
contained in RAMS-I messages, including burst bitrate. Only in the case when
the RS decided to change the burst bitrate according to a subsequent RAMS-R
message received, the subsequent RAMS-R message indirectly triggers a RAMS-I
message. The process to me seems rather simple. 
 
BR, YK

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill
Ver Steeg (versteb)
Sent: Wednesday, April 01, 2009 7:52 PM
To: Bill Ver Steeg (versteb); Zeev Vax; [email-masked];
Ali C. Begen (abegen)
Cc: [email-masked]
Subject: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple
RAMS-R messages for the same unicast flow

When we added the ability to send more than one RAMS-R message, we opened up
a few design points that we now need to consider.

The first design point I would like to address is what the RS is required to
do when it receives an RAMS-R for a burst that is already in flow (aka
"subsequent RMS-R"). We stated that the least it could do was "ignore it".
Does this imply that there is no requirement to send an RMS-I in response to
RMS-R messages referencing an in-progress flow? If so, we should add
clarifying text in the document that cautions the RR not to assume the
RAMS-R was dropped. I briefly considered requiring the RS to send a RAMS-I
for each received RAMS-R. Unfortunately, this then leads to another set of
corner cases, and may result in a chatty exchange of messages.

We also need to consider how to deterministically differentiate between the
initial RMS-R message and subsequent RMS-R messages, particularly in the
event of packet loss or (unlikely) re-ordering. This probably leads us to
including a monotonically increasing sequence number on the RMS-R. Dropped
RMS-R messages should not be a protocol problem, as the first one received
will trigger the burst. Subsequent RMS-R messages either change the burst
shape or they do not, and they do not trigger additional messages.
Similarly, if the initial RMS-I is dropped it will probably trigger an
additional RMS-R message. Subsequent RMS-I messages will either be received
by the RR or they will not, and they will not trigger additional messages.

So, has anybody considered these design points in detail? I have started to
go down this path, but it gets complicated quickly.

In order to limit the complexity, I suggest that we state that the first
received RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further
RMS-I messages may also flow, but there is no explicit requirement to send
an RMS-I in response to a subsequent RMS-R.

Bill VerSteeg

---

From: David R Oran <[email-masked]>
Date: Wed, 1 Apr 2009 21:01:46 -0400

On Apr 1, 2009, at 7:52 PM, Bill Ver Steeg (versteb) wrote:

> We need to have some nomenclature for describing the "initial RMS-R"  
> and "subsequent RMS-R", so I will start with using those words.  
> Better words would be appreciated.
>
> required to do when it receives an RAMS-R for a burst that is  
> already in flow (aka "subsequent RMS-R"). We stated that the least  
> it could do was "ignore it". Does this imply that there is no  
> requirement to send an RMS-I in response to RMS-R messages  
> referencing an in-progress flow?
>
No. In order to have rational state machines the RS MUST reply to each  
RAMS-R with a RAMS-I. Whether there is a "Reference to the in-progress  
flow" is a secondary issue. The key point is that semantically the  
RAMS-I returned in response to a RAMS-R can be (from a state machine  
point of view) no different from the first, because either the RS may  
never have received the first RAMS-R, or conversely the RAMS-I sent in  
response to te earlier RAMS-R might have been lost.

This is how protocols utilizing idempotency semantics have to operate.
> If so, we should add clarifying text in the document that cautions  
> the RR not to assume the RAMS-R was dropped.
>
Well, "caution" is not the term I would use. Just show the state  
machines and the whole thins should be obvious (at least it would be  
to me).
> I briefly considered requiring the RS to send a RAMS-I for each  
> received RAMS-R. Unfortunately, this then leads to another set of  
Uh, I don't think so. The only time a message other than the two  
needed to initiate a burst is sent is if a message is lost. Worst case  
this is one extra message - if the sequence is RAMS-R->RAMS- 
I(lost)...RAMS-R(retry)->RAMS-I.
As long as none of the fields in the messages have themselves non- 
idempotent semantics (e.g. by being deltas rather than absolute  
values) I fail to see what corner cases arise.
> We also need to consider how to deterministically differentiate  
> between the initial RMS-R message and subsequent RMS-R messages,  
> particularly in the event of packet loss or (unlikely) re-ordering.
>
I would argue that we in fact don't need to do this as long as we wait  
long enough for retransmission to avoid delayed duplicates or messages  
crossing on the wire. If that is that is the case I would much prefer  
that we use transaction ids instead of or in addition to sequence  
numbers. But I think neither is in fact necessary

In low-probability case the RAMS-R messages permute, the client can  
always recover by sending another RAMS-R with the burst rate it wants.

What this does point out however, is that we should have either  
DIFFERENT fields for the values in the RAMS-I that are meant to echo/ 
confirm values requested by the RAMS-R, versus those set unilaterally  
by the server, or use a DIFFERENT message type for a unilateral RAMs- 
(something other than -I) generate by the RS that was not triggered by  
receipt of a RAMS-R.

Either would work.

> This probably leads us to including a monotonically increasing  
> sequence number on the RMS-R.
>
This begs the question of who throws away state when. For example, if  
I try to do a RAMS on multicast group 1, give up, try to do a RAMS on  
multicast group 2, give up, and then try to do a RAMS on group 1  
again. What sequence number does the last of these RAMS-R message  
have? Why would it be different than if I never had done the RAMS-R on  
flow 2? How can the RS possibly know which case obtains?

I think we're actually making the protocol much more complicated and  
with more error states by introducing sequencing to avoid the problems  
that would arise from permuted messages on a retransmission time-out.  
It's just so much easier to ensure all the protocol semantics are  
idempotent.
>  Dropped RMS-R messages should not be a protocol problem, as the  
> first one received will trigger the burst. Subsequent RMS-R messages  
> either change the burst shape or they do not, and they do not  
Really? Not if they have sequence numbers and the RS failed to forget  
the state of an earlier burst.
> Similarly, if the initial RMS-I is dropped it will probably trigger  
> an additional RMS-R message. Subsequent RMS-I messages will either  
> be received by the RR or they will not, and they will not trigger  
> additional messages.
>
> So, has anybody considered these design points in detail?
>
Yes. Not for RAMS, but for numerous other request/response protocols  
that operate idempotently.
> I have started to go down this path, but it gets complicated quickly.
>
So you're discovering :-)
> In order to limit the complexity, I suggest that we state that the  
> first received RMS-R triggers a RMS-I. Further RMS-R messages may  
> flow. Further RMS-I messages may also flow, but there is no explicit  
No, this is a bug. It never allows the client to ascertain the state  
of the server.

DaveO.

>
> Bill VerSteeg
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 1 Apr 2009 21:01:28 -0400

Thanks YK-
 
This is also where I ended up. Simple is good.
 
I will be sure that the text is clear in this regard.
 
bvs

From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Wednesday, April 01, 2009 8:53 PM
To: Bill Ver Steeg (versteb); 'Zeev Vax';
[email-masked]; Ali C. Begen (abegen)
Cc: [email-masked]
Subject: RE: [AVT] Rapid Acquisition of Multicast Streams (RAMS) -
multipleRAMS-R messages for the same unicast flow

Sending of subsequent RAMS-I messages by the RS is not trigged by
reception of RAMS-R messages, but by that the server has decided to
change information contained in RAMS-I messages, including burst
bitrate. Only in the case when the RS decided to change the burst
bitrate according to a subsequent RAMS-R message received, the
subsequent RAMS-R message indirectly triggers a RAMS-I message. The
process to me seems rather simple. 
 
BR, YK

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bill Ver Steeg (versteb)
	Sent: Wednesday, April 01, 2009 7:52 PM
	To: Bill Ver Steeg (versteb); Zeev Vax;
[email-masked]; Ali C. Begen (abegen)
	Cc: [email-masked]
	Subject: [AVT] Rapid Acquisition of Multicast Streams (RAMS) -
multiple RAMS-R messages for the same unicast flow

	When we added the ability to send more than one RAMS-R message,
we opened up a few design points that we now need to consider.

	We need to have some nomenclature for describing the "initial
RMS-R" and "subsequent RMS-R", so I will start with using those words.
Better words would be appreciated.

	We also need to consider how to deterministically differentiate
between the initial RMS-R message and subsequent RMS-R messages,
particularly in the event of packet loss or (unlikely) re-ordering. This
probably leads us to including a monotonically increasing sequence
number on the RMS-R. Dropped RMS-R messages should not be a protocol
problem, as the first one received will trigger the burst. Subsequent
RMS-R messages either change the burst shape or they do not, and they do
not trigger additional messages. Similarly, if the initial RMS-I is
dropped it will probably trigger an additional RMS-R message. Subsequent
RMS-I messages will either be received by the RR or they will not, and
they will not trigger additional messages.

	So, has anybody considered these design points in detail? I have
started to go down this path, but it gets complicated quickly.

	In order to limit the complexity, I suggest that we state that
the first received RMS-R triggers a RMS-I. Further RMS-R messages may
flow. Further RMS-I messages may also flow, but there is no explicit
requirement to send an RMS-I in response to a subsequent RMS-R.

	Bill VerSteeg

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 1 Apr 2009 21:04:29 -0400

Based on further responses, the jury is still out.
 
I will mark this section of the text with an editor's note and we will
continue the discussion.
 
bvs

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bill Ver Steeg (versteb)
Sent: Wednesday, April 01, 2009 9:01 PM
To: Ye-Kui Wang; Zeev Vax; [email-masked]; Ali C.
Begen (abegen)
Cc: [email-masked]
Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS)
-multipleRAMS-R messages for the same unicast flow

Thanks YK-

 
bvs

 
BR, YK

	 

	Bill VerSteeg

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 01 Apr 2009 22:33:15 -0400

I am leaving all but the last comment from Dave for Bill.
 
> No, this is a bug. It never allows the client to ascertain the state  

This relates to the discussion about loss of RMS-I message during Bill's
presentation in San Francisco. My understanding then and also now is as
follows. If during the burst, the burst bitrate is changed by the RS due to
whatever reason, and the RS has not sent an RMS-I or the sent RMS-I was
lost, it should not be a disater to the client as it knows the its buffer
status, and it can also know the change of the burst bitrate and even the
value of the changed burst bitrate if it wants. So why there is a problem
here?

BR, YK

> -----Original Message-----
> Behalf Of David R Oran
> Sent: Wednesday, April 01, 2009 9:02 PM
> To: Bill Ver Steeg (versteb)
> Cc: [email-masked]; [email-masked]; Zeev Vax
> Subject: Re: [AVT] Rapid Acquisition of Multicast Streams 
> (RAMS) - multipleRAMS-R messages for the same unicast flow
> 
> 
> > required to do when it receives an RAMS-R for a burst that 
> is already 
> > in flow (aka "subsequent RMS-R"). We stated that the least 
> it could do 
> > was "ignore it". Does this imply that there is no 
> requirement to send 
> > an RMS-I in response to RMS-R messages referencing an in-progress 
> > flow?
> >
> No. In order to have rational state machines the RS MUST 
> reply to each RAMS-R with a RAMS-I. Whether there is a 
> "Reference to the in-progress flow" is a secondary issue. The 
> key point is that semantically the RAMS-I returned in 
> response to a RAMS-R can be (from a state machine point of 
> view) no different from the first, because either the RS may 
> never have received the first RAMS-R, or conversely the 
> RAMS-I sent in response to te earlier RAMS-R might have been lost.
> 
> > If so, we should add clarifying text in the document that 
> cautions the 
> > RR not to assume the RAMS-R was dropped.
> >
> Well, "caution" is not the term I would use. Just show the 
> state machines and the whole thins should be obvious (at 
> least it would be to me).
> Uh, I don't think so. The only time a message other than the 
> two needed to initiate a burst is sent is if a message is 
> lost. Worst case this is one extra message - if the sequence 
> is RAMS-R->RAMS- I(lost)...RAMS-R(retry)->RAMS-I.
> As long as none of the fields in the messages have themselves 
> non- idempotent semantics (e.g. by being deltas rather than absolute
> I would argue that we in fact don't need to do this as long 
> as we wait long enough for retransmission to avoid delayed 
> duplicates or messages crossing on the wire. If that is that 
> is the case I would much prefer that we use transaction ids 
> instead of or in addition to sequence numbers. But I think 
> neither is in fact necessary
> 
> In low-probability case the RAMS-R messages permute, the 
> client can always recover by sending another RAMS-R with the 
> burst rate it wants.
> 
> What this does point out however, is that we should have 
> either DIFFERENT fields for the values in the RAMS-I that are 
> meant to echo/ confirm values requested by the RAMS-R, versus 
> those set unilaterally by the server, or use a DIFFERENT 
> message type for a unilateral RAMs- (something other than -I) 
> generate by the RS that was not triggered by receipt of a RAMS-R.
> 
> Either would work.
> 
> 
> This begs the question of who throws away state when. For 
> example, if I try to do a RAMS on multicast group 1, give up, 
> try to do a RAMS on multicast group 2, give up, and then try 
> to do a RAMS on group 1 again. What sequence number does the 
> last of these RAMS-R message have? Why would it be different 
> than if I never had done the RAMS-R on flow 2? How can the RS 
> possibly know which case obtains?
> 
> I think we're actually making the protocol much more 
> complicated and with more error states by introducing 
> sequencing to avoid the problems that would arise from 
> permuted messages on a retransmission time-out.  
> It's just so much easier to ensure all the protocol semantics 
> are idempotent.
> Really? Not if they have sequence numbers and the RS failed 
> to forget the state of an earlier burst.
> > additional RMS-R message. Subsequent RMS-I messages will either be 
> > received by the RR or they will not, and they will not trigger 
> > additional messages.
> >
> Yes. Not for RAMS, but for numerous other request/response 
> protocols that operate idempotently.

---

From: David R Oran <[email-masked]>
Date: Wed, 1 Apr 2009 22:38:52 -0400

> value of the changed burst bitrate if it wants. So why there is a  
The client doesn't know if the burst is going to start or not, or if  
the RS aborted the burst, or finished it. The client can't tell  
whether the RS failed to send an RAMS-I because it lost the RAMS-R or  
because it thought it was redundant - in a client/server protocol each  
request needs to be replied to with a response for the state machines  
to clean up correctly.

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 01 Apr 2009 22:57:23 -0400

> > This relates to the discussion about loss of RMS-I message during 
> > Bill's presentation in San Francisco. My understanding then 
> and also 
> > now is as follows. If during the burst, the burst bitrate 
> is changed 
> > by the RS due to whatever reason, and the RS has not sent 
> an RMS-I or 
> > the sent RMS-I was lost, it should not be a disater to the 
> client as 
> > it knows the its buffer status, and it can also know the 
> change of the 
> > burst bitrate and even the value of the changed burst bitrate if it 
> > wants. So why there is a problem here?
> >
> The client doesn't know if the burst is going to start or not,

The client knows that the burst started if burst packets are coming. Of
course the first RMS-I message is still important.

> or if the RS aborted the burst, or finished it. The 

Isn't that the RS only aborts the burst after receiving RMS-T or BYE
message? And no draft has mentioned using a message from RS to tell that it
will abort or finish the burst anyway. 

> client can't tell whether the RS failed to send an RAMS-I 
> because it lost the RAMS-R or because it thought it was 
> redundant - in a client/server protocol each request needs to 
> be replied to with a response for the state machines to clean 
> up correctly.

Agreed. 

BR, YK

---

From: Peilin YANG <[email-masked]>
Date: Thu, 02 Apr 2009 16:39:42 +0800

The RS shall reply to each RAMS-R fom the viewpoint of state machine.Nevertheless, 
subsequent RAMS-I messages is not trigged by reception of RAMS-R messages, 
so I also think that adding a DIFFERENT field for the values in the RAMS-I should be a good choice. 
In the meantime this can avoid having a seqnum on 2 of the 3 messages.

Regards,

Peilin

----- 原邮件 -----
发件人: David R Oran <[email-masked]>
日期: 星期四, 四月 2日, 2009 上午9:02
主题: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow
收件人: "Bill Ver Steeg (versteb)" <[email-masked]>
抄送: [email-masked], [email-masked], Zeev Vax <[email-masked]>

> we  
> RMS-R"  
> cautions  
> > I have started to go down this path, but it gets complicated 
> quickly.>
> the

---

From: Zou ZiXuan <[email-masked]>
Date: Thu, 02 Apr 2009 19:53:19 +0800

> subsequent RAMS-I messages is not trigged by reception of RAMS-R
[ZiXuan] If subsequent RAM-I message is not triggered by reception of
RAMS-R, then why do we need a DIFFERENT field in the RAMS-I message? I
guess you meant those RAMS-I messages generated unilaterally by RS, is
my understanding correct?
> so I also think that adding a DIFFERENT field for the values in the
RAMS-I
> should be a good choice.
************************************************************************
************
> ******
>  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
************************************************************************
************
> *****
> 主题: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) -
multiple

---

From: Peilin YANG <[email-masked]>
Date: Thu, 02 Apr 2009 20:03:52 +0800

Yes, your understanding is corrrect. That is my meaning.

Peilin

----- 原邮件 -----
发件人: Zou ZiXuan <[email-masked]>
日期: 星期四, 四月 2日, 2009 下午7:55
主题: RE: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow
收件人: 'Peilin YANG' <[email-masked]>, 'David R Oran' <[email-masked]>, "'Bill Ver Steeg (versteb)'" <[email-masked]>, [email-masked], 'Zeev Vax' <[email-masked]>
抄送: [email-masked]

> > In the meantime this can avoid having a seqnum on 2 of the 3 
> messages.> 
> > Regards,
> > 
> > Peilin
> > 
> >
> >  This email and its attachments contain confidential information 
> from> HUAWEI, which is intended only for the person or entity 
> whose address
> is
> non-
> > > have? Why would it be different than if I never had done the 
> RAMS-
> > > R on
> > > that would arise from permuted messages on a retransmission 
> time-
> > > out.

---

From: Zeev Vax <[email-masked]>
Date: Wed, 1 Apr 2009 10:08:43 -0700

Bill,

Please send me the draft for review once you are done with your editorial path, before we send it out for review I would like to add my changes to the draft.

Zeev

From: Bill Ver Steeg (versteb) [mailto:[email-masked]]
Sent: Tuesday, March 31, 2009 11:46 AM
To: [email-masked]; Zeev Vax; [email-masked]; Ali C. Begen (abegen)
Subject: Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields

One of the primary action items arising from the review of the Rapid Acquisition of Multicast Streams  draft is to identify which fields are mandatory (and thus fixed format) and which fields are optional (and thus TLV format). Here is my take on the matter. Once we reach consensus, I will update the draft.

I have also included a description of the requested "motivating text" for the fields that do not already have such text in the document. Please let me know if I am on the right track.

There is currently no version number in the messages. Ali and I do not think that this is a problem because we can add new TLVs as needed. I want to be sure we intentionally decide on this point rather than back into it accidently. Any comments?

We have 3 messages -

RAMS-Request
 Max Receive BitRate - mandatory
 Min Buffer Fill Requirement - optional ( Add wording - The receiver may have knowledge of it's buffering requirements. These requirements may be application or device specific. For instance, the receiver may need to have a certain amount of data in it's application buffer to handle interdependency within the data. If the RS knows the buffering ability of the receiver, it may more precisely tailor the burst to the client. The methods used by the receiver to determine this value is application specific, and thus out of scope. This mechanism can be used by the receiver to signal the sender, if the receiver has such knowledge )
 Max Buffer Fill Requirement - optional ( Add wording - The receiver may have knowledge of it's buffering requirements. These requirements may be application or device specific. For instance, one receiver may have more physical memory than another receiver, and thus can buffer more data. If the RS knows the buffering ability of the receiver, it may more precisely tailor the burst to the client. The methods used by the receiver to determine this value is application specific, and thus out of scope. This mechanism can be used by the receiver to signal the sender, if the receiver has such knowledge )

RAMS- Inform
 message Sequence Number - mandatory
 Response - mandatory, will include an enumerated list of response codes - 0 is succeed, non zero is an error code. We will enumerate a list of error codes, and note that additional error codes are possible using vendor-specific TLV fields. The enumerated errors will include [No server resources, No network resources, bad RMS-R request, WHAT ELSE????] Note - we have removed the "join now semantic, as that is captured in the "earliest join time" field.
 Reserved - mandatory - must be all 0s
 Max Burst Bitrate - mandatory
 Rapid Acquisition Duration - mandatory - 0 means "join now" (Add wording to reflect that this is the server's current value, and can be changed by subsequent RMS-I. Add wording to reflect that the RS can't consume resources forever and needs to deterministically stop the flow. The RS MUST terminate the flow at this time, even if does not get RMS-T from the RR.  )
 Extended RTP Sequence Number of First Burst Packet - mandatory
 Earliest IGMP Join Time - optional (we should consider making this mandatory in at least one RMS-I, as the client needs to eventually join)

Rams -Terminate -
  Extended RTP seqnum of First Multicast packet - optional (intent is to tell the RS the seqnum at which to stop the burst, but leave the session open. If the field is not present, it means "stop now")

Bill VerSteeg

---

From: Zeev Vax <[email-masked]>
Date: Wed, 1 Apr 2009 19:51:34 -0700

I agree with your conclusions, giving possible packet lose and the fact the RS is not required to act on subsequent RMS-R, this would be the best way to keep it simple.
The statement I'm referring to is

"In order to limit the complexity, I suggest that we state that the first received RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further RMS-I messages may also flow, but there is no explicit requirement to send an RMS-I in response to a subsequent RMS-R."
I don't think we need and monotonically increased  sequence number, relaying on that will only complicate the RS decision making and error handling.

Zeev

From: Bill Ver Steeg (versteb) [mailto:[email-masked]]
Sent: Wednesday, April 01, 2009 4:52 PM
To: Bill Ver Steeg (versteb); Zeev Vax; [email-masked]; Ali C. Begen (abegen)
Cc: [email-masked]
Subject: Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow

When we added the ability to send more than one RAMS-R message, we opened up a few design points that we now need to consider.

We need to have some nomenclature for describing the "initial RMS-R" and "subsequent RMS-R", so I will start with using those words. Better words would be appreciated.

The first design point I would like to address is what the RS is required to do when it receives an RAMS-R for a burst that is already in flow (aka "subsequent RMS-R"). We stated that the least it could do was "ignore it". Does this imply that there is no requirement to send an RMS-I in response to RMS-R messages referencing an in-progress flow? If so, we should add clarifying text in the document that cautions the RR not to assume the RAMS-R was dropped. I briefly considered requiring the RS to send a RAMS-I for each received RAMS-R. Unfortunately, this then leads to another set of corner cases, and may result in a chatty exchange of messages.

We also need to consider how to deterministically differentiate between the initial RMS-R message and subsequent RMS-R messages, particularly in the event of packet loss or (unlikely) re-ordering. This probably leads us to including a monotonically increasing sequence number on the RMS-R. Dropped RMS-R messages should not be a protocol problem, as the first one received will trigger the burst. Subsequent RMS-R messages either change the burst shape or they do not, and they do not trigger additional messages. Similarly, if the initial RMS-I is dropped it will probably trigger an additional RMS-R message. Subsequent RMS-I messages will either be received by the RR or they will not, and they will not trigger additional messages.

So, has anybody considered these design points in detail? I have started to go down this path, but it gets complicated quickly.

In order to limit the complexity, I suggest that we state that the first received RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further RMS-I messages may also flow, but there is no explicit requirement to send an RMS-I in response to a subsequent RMS-R.

Bill VerSteeg

---

From: David R Oran <[email-masked]>
Date: Thu, 2 Apr 2009 13:10:27 -0400

> my understanding correct?
Yes, sorry if that wasn't clear.
DaveO
>> messages.