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

[Peilin YANG <yangpeilin at huawei.com>]

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)" <versteb at cisco.com>
日期: 星期三, 四月 1日, 2009 上午2:46
主题: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields
收件人: avt at ietf.org, zeevvax at microsoft.com, Tom.Van_Caenegem at alcatel-lucent.be, "Ali C. Begen (abegen)" <abegen at cisco.com>

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