On Mar 30, 2009, at 10:28 AM, VAN CAENEGEM Tom wrote:
I think reject reasons are a good idea, with a real IANA error registry. Vendor extensibility is fine, but having a comprehensive standard error lexicon is just good engineering. I'll note that even more important than error codes to the client are the error reporting capabilities "northbound" out of the servers. This is because for large scale environments lide the ones we see in the sue cases for rapid multicast acquisition, we are probably just pushing the problem around by sending diagnostic information to the client, who likely can't do much of anything with it anyway.Hi Peilin,Thanks for your comments. For those that concern editorial stuff, I have no comments back. I have comments on three of your suggested modification items, as explained below.Kind regards Tom Item 1) RMS-I message You wrote:"In the RMS-I message, the present values of Response include 0,1 and 2. The value of 0 indicates that the rapid synchronization request has been rejected. Nevertheless, in the RMS-I message there is not a field to indicate a rejected reason. In my point of view, tt is easier for RR to understand the rejected reason if there is a field of reason. What's more, it is convenient to make statistics report.The following Figure is my proposal. (..) "TOM : in any case the message formats will be revised to describe parameters as much as possible and/or useful by means of(optional) TLV fields. I believe Bill will make a proposal soon. I think the "cause of rejection" may be such a TLV field, when the RS indeed rejects the Burst Request. However, I think that may well be a vendor-specific field (for which we need a "type" classifier), as there are many reasons why a request is not honored, but to list them would IMO be out of scope of this draft. So, the question is: do we define a Type for a TLV extension that we call e.g. "reason of rejection" or do we just stick to a Type that only means " vendor specific". I think in both cases, an RR and a RS of a different vendor will not understand each-other, so we may well make it very generic and only define a TLV "type" that means " vendor specific"
So, I think we should add this for good engineering, but hope people realize that in reality it won't help much.
I agree with Tom. Even an initial RAMS-R the server is free to ignore the (optional) bitrate parameter.Item 2) Section 6.2: Message flows3. Updated Request: The RR MAY send a new RMS-R message with a different valule of the field Max Receive Bitrate. The RS MAY use this updated bitrate for sending the burst, or refine the value and use the refined value for sending the burst. In any of the cases, the RS MAY send an RMS-I to indicate the bitrate being used. In case the RS receives multiple RMS-R messages at the same time, the latest RMS-R message, as indicated by the value of the MSN field in the RMS-R message, MUSTbe used, and other RMS-R messages SHOULD be discarded. TOM: I suggest to delete " In case the RS receivesmultiple RMS-R messages at the same time, the latest RMS-R message, as indicated by the value of the MSN field in the RMS-R message, MUSTbe used, and other RMS-R messages SHOULD be discarded."This is because an RS may not support the feature of flexible burst rate adaptation under control of the RR. Hence in that case its implementation may be such that it classifies incoming RMS-R based on version number and internal state. When the RS has already an active thread for a certain RR and certain SSM (a pending or active burst request) , the RS can simply drop any new RMS-R (with a higher message sequence number) transmitted by that specific RR for that specific ssm.
I think the problems with mis-ordering of conrol messages spaced at greater than an RTT are not so great as to put a lot of effort into strict sequence numbering, at least not something beyond what RTCP provides itself.Item 3) Section on RMS-R message (section 7.1) Message Sequence Number (8 bits) : During rapid synchronization, the RMS-R message(s) may be sent more than once. The first RMS-Rmessage SHALL have an MSN value of 0. If a new information is conveyed in a new RMS-R message, the MSN value SHALL be incremented by one.TOM: an RMS-R message may also be sent multiple times with the same information for redundancy purposes. For that reason, I suggest we have instead of " If a new information is conveyed in a new RMS-R message, the MSN value SHALL be incremented by one ", we are more specific and align with the phrasing as used for the RMS-I message: "This value SHALL NOT be changed if the same RMS-R message is sent to the same RS multiple times for redundancy purposes. If a new information is conveyed in a new RMS-R message, the MSN value SHALL be incremented by one"
DaveO.