Re: [RPRWG] What rcvdFairRate should be used if SC-FCM are not being received?
I thought we had resolved the comment you made on the TTL decrement
issue for FCMs in Table 9.5, Prasenjit.
Was the resolution we made insufficient?
Secondly, on the comment by Michael Allen on the use of
"unreserved rate" for the initial value of rcvdFairRate, I do not
understand why this implies that "the" downstream node is congested?
Wouldn't the use of unreserved rate imply that this node is not limited by
any downstream node? I would think this is the right value to use as the
starting point, if we would like to enable fast start, and we shouldn't
have any notion of which node (or an associated SA) downstream is
congested. I fail to see why use of FULL_RATE would avoid any problem.
It might be helpful to understand why the use of FULL_RATE rather than
unreservedRate is better.
Thanks,
K. K. Ramakrishnan
Prasenjit Biswas wrote:
>I had submitted a comment on the same issue (TTL decrement in table 9.5)
>for the last meeting.
>Draft2.1 could be updated as a response to that comment and Table 9.2
>could reflect the change.
>
>Prasenjit Biswas
>
>
>Necdet Uzun wrote:
>
>
>>Michael,
>>
>>Thanks for catching the TTL decrement issue for fairness frames. We need to
>>modify either Table 9.x or Table 6.17 to decrement TTL of fairness frame as you
>>proposed. If we do it in clause 9, I prefer it to be done in Table 9.2 as soon
>>as frame is received. Would you be submitting a comment for it?
>>
>>Thanks.
>>
>>Necdet
>>
>>Michael Allen wrote:
>>
>>
>>
>>>Necdet:
>>>
>>>I am not sure I agree with your answer for 3). My response is marked [MDA]:
>>>
>>>Regards,
>>>
>>>Michael
>>>
>>>-----Original Message-----
>>>From: Necdet Uzun [mailto:nuzun@xxxxxxxxx]
>>>Sent: Monday, January 20, 2003 2:32 PM
>>>To: Michael Allen
>>>Cc: John Lemon; stds-802-17@xxxxxxxx
>>>Subject: Re: [RPRWG] What rcvdFairRate should be used if SC-FCM are not
>>>being received?
>>>
>>>Michael,
>>>
>>>Please see my comments.
>>>
>>>Thanks.
>>>
>>>Necdet
>>>
>>>Michael Allen wrote:
>>>
>>>
>>>
>>>>John:
>>>>
>>>>Thanks for your answers. I must admit, I missed the Clause 11 statement
>>>>about missing SC-FCM messages. Shouldn't the Fairness state machines have
>>>>some states that reflect the missing messages and generate a failure
>>>>indication to the protection state machine?
>>>>
>>>>It looks like the initial value of rcvdFairRate has proponents for two
>>>>values:
>>>> FULL_RATE
>>>> unreservedRate
>>>>
>>>>
>>>I would say unreservedRate.
>>>
>>>
>>>
>>>>Also, some extra questions...
>>>>
>>>>1) In Table 9.2, "wrappedRing" is not defined. Is this meant to mean "I am
>>>>wrapped", or "the ring is wrapped somewhere"?
>>>>
>>>>
>>>A wrapping protection somewhere on the ring.
>>>
>>>
>>>
>>>>2) In Table 9.2, for the wrapped congested case, shouldn't the formula be:
>>>>hopsToCongestion = hopsToWrappedDownstreamStation + (256 - rcvdTTL);
>>>>Assuming hops are not decremented on the "wrong" ring ID.
>>>>
>>>>
>>>Any packet going beyond WrappedDownstreamStation would go through the
>>>congestion
>>>point if the congested station is on opposite ringlet. Hence, the table is
>>>right.
>>>
>>>
>>>
>>>>3) In Table 9.5, Row 2, Line 26 (msg.TTL = rcvdTTL), shouldn't this be
>>>>replaced with:
>>>>if (rcvdRI == ringId)
>>>>{
>>>> msg.TTL = rcvdTTL - 1;
>>>>}
>>>>else
>>>>{
>>>> msg.TTL = rcvdTTL;
>>>>}
>>>>
>>>>
>>>>
>>>Table 9.5 assumes that data path already decremented TTL based on the rules
>>>described in clause 6. So TTL is not decremented in FCU. Hence, the table
>>>9.5
>>>row 2 is right.
>>>
>>>[MDA]: An SC-FCM would enter Table 6.17, and pass Row 9 moving to state
>>>TEST.
>>>[MDA]: Next, Row 13 would match moving to state COPY
>>>[MDA]: Next, Row 21 which performs copyToControl(). This function does not
>>>decrement
>>> any TTL field.
>>>[MDA]: If the packet is an SC-FCM, it is discaarded in Row 27 (after having
>>>the TTL
>>> decremented), but the packet has already been delivered to the
>>>control processor.
>>>
>>>[MDA]: As such, I still believe the code I propose above is needed in the
>>>fairness
>>> message processor.
>>>
>>>
>>>
>>>>Regards,
>>>>
>>>>Michael Allen
>>>>
>>>>-----Original Message-----
>>>>From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
>>>>[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of John Lemon
>>>>Sent: Monday, January 20, 2003 11:21 AM
>>>>To: Michael Allen; stds-802-17@xxxxxxxx
>>>>Subject: RE: [RPRWG] What rcvdFairRate should be used if SC-FCM are not
>>>>being received?
>>>>
>>>>Michael,
>>>>
>>>>My answers:
>>>>
>>>>1) Good catch. It is not stated, and therefore needs to be. (I'll expect a
>>>>comment from you against D2.1 to address this issue.) My recommendation
>>>>would be to initialize the last rcvdFairRate with the same value the
>>>>localFairRate is initialized with.
>>>>
>>>>2) From a fairness control unit point of view, it does not time out. (See
>>>>(3) for why it doesn't need to.) Whatever the last one was, is the one
>>>>
>>>>
>>>used.
>>>
>>>
>>>>3) Yes. Note that this is already specified in Clause 11.
>>>>
>>>>John Lemon
>>>>
>>>>-----Original Message-----
>>>>From: Michael Allen [mailto:michael_allen@xxxxxxxxxxxxxxx]
>>>>Sent: Sunday, January 19, 2003 2:05 PM
>>>>To: stds-802-17@xxxxxxxx
>>>>Subject: [RPRWG] What rcvdFairRate should be used if SC-FCM are not
>>>>being received?
>>>>
>>>>In section 9.3.1 of D2.0, it indicates that the most recently received
>>>>rcvdFairRate value should be used in the aging interval calculations.
>>>>
>>>>My questions relate to this.
>>>>
>>>>1) What rcvdFairRate should be assumed if a rcvdFairRate has *never* been
>>>>received. Should a rcvdFairRate of FFFFh be assumed initially?
>>>>
>>>>2) What rcvdFairRate should be assumed if a rcvdFairRate has not been
>>>>received for "a while" (like 10 or N intervals), but has been received at
>>>>least once. Should a rcvdFairRate of FFFFh be assumed after this period?
>>>>
>>>>3) Should a Signal Fail indication be sent to the Protection Machine if 2)
>>>>occurs?
>>>>
>>>>Regards,
>>>>
>>>>Michael Allen
>>>>Chip Engines, Inc
>>>>
>>>>
--
K. K. Ramakrishnan Email:kkrama@xxxxxxxxxxxxxxxx
AT&T Labs-Research, Rm. A117 Tel: (973)360-8764
180 Park Ave,Florham Park,N.J. 07932 Fax: (973) 360-8871
URL: http://www.research.att.com/info/kkrama