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.
David V. James
3180 South Ct
Palo Alto, CA 94306
Michael,
With regards to the following:
>> 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, ...
I am concerned, in general, about the fairness TTL and how it is used.
1) I think it should always be "1" when the frame is sent, since
it is always stripped by the downstream neighbor.
2) Some other field should be used to represent the 9-bit congestion
location.
3) The congestion location is a 9-bit field, since that is the number
of possible congestion locations on a wrapped ringlet.
Just a bit of stimulating food for thought...
DVJ
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@xxxxxxxxxxxx
>> -----Original Message-----
>> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
>> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Michael Allen
>> Sent: Tuesday, January 21, 2003 10:23 AM
>> To: K. K. Ramakrishnan; Prasenjit Biswas
>> Cc: Necdet Uzun; John Lemon; stds-802-17@xxxxxxxx
>> Subject: 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
>>
>>
>>
>>