RE: [RPRWG] What rcvdFairRate should be used if SC-FCM are not being received?
I am assuming you are talking about comment 941 for TTL decrement. The
resolution indicates the TTL is decremented in the data path and no actual
fix is needed in Clause 9, which I believe is incorrect as shown by my
comments below (labeled [MDA]) and acknowledged by Necdet. I believe the
resolution was incorrect, so I will submit a comment to that effect for
D2.1. It would seem like my proposed resolution differs from the resolution
comments & this would prohibit including the change in D2.1.
Regarding the initial value of rcvdFairRate, I do not understand all the
math involved. My reasoning behind believing the downstream node must be
congested by initializing rcvdFairRate to unreservedRate is that I
understand rcvdFairRate != FULL_RATE to mean congestion. If you use
unreservedRate (which != FULL_RATE), to me that indicates congestion. I
suppose that is OK, since that stops a new node coming on-line on a busy
ring and blasting the ring before it figures out a natural balance. I am
happy to let people more knowledgeable than me decide this initial value.
Regards,
Michael Allen
-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of K. K.
Ramakrishnan
Sent: Monday, January 20, 2003 6:52 PM
To: Prasenjit Biswas
Cc: Necdet Uzun; Michael Allen; John Lemon; stds-802-17@xxxxxxxx
Subject: 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