|
All,
As
editor of the pseudo-C code, I would like to confirm that:
1) The C-code is intended to be informational.
2) The quality of the current C-code is insufficient for even
(1).
Before massive cosmetic
changes by the editor, the lines of
error messages far
outlined the lines of code.
For
now, its better to work on correcting the C-code than
quoting it.
On the
topic of single and dual buffers. The same functionality
(small
silicon) appears achievable by mandating dual buffers,
but
allowing the lower-class transit buffer to be fairly small in
size.
DVJ
I
hope folks have submitted comments on the TX flow-chart on page
48
or
Necdet you have caught this?
One
amusing sequence is:
If
MP TX is less than CIR, Then if MP TX is available, Then mark the packet
OUT-OF-PROFILE
Boy,
did MP packet get into the wrong queue !!
raj
Bob,
You are right. We need to have more detail on this in the normative
section (9.3) of the standard.
Thanks.
Necdet
RDLove wrote:
Necdet, your response to Raj provides an
opportunity to remind everyone that although pseudo-code may be an
excellent way to get some idea of how standards compliant hardware could
work, it is an exemplary implementation only, and is in an informative,
not normative standard, which is where it belongs. Necdet, I don't
find any fault in your pointing to the pseudo-code to show how things
might work. However, it is vital that the IEEE 802.17 standard has a
normative portion that precisely and comprehensively defines standard
based behavior for all compliant hardware. I expect we will need the
equivalent of state machine diagrams and tables to accomplish this vital
function. Best regards, Robert D. Love
Chair,
Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919
810-7816
email: rdlove@xxxxxxxx
Fax: 208 978-1187
----- Original Message -----
Sent: Wednesday, March 06, 2002
2:39 PM
Subject: Re: [RPRWG] Single and
dual transit buffer MACs Raj,
If you look at the psuedo code at Annex H
page 247 line 3:
UpdatedEveryClockCycle(Station * sPtr)
{
// tokenOctets is
decremented by 1 for every LP/eMP octet that is transmitted by the
client.
// A packet is sent to completion, why is the below check
here?
if ((sPtr->addRateCongestion <
sPtr->allowRateCongestion) &&
(sPtr->fwdRate +
sPtr->addRate + sPtr->rate_iMP < MAX_LRATE -
sPtr->reservedRate) &&
... )
sPtr->addRateOk
= TRUE; // true means OK to send client packets
This check ensures that there is enough BW at the outgoing link for
the reserved traffic, otherwise client will not be able to add eMP or LP
packets to the ring (this will reduce the advertised fair rate as well).
This will ensure that there is enough BW reserved on the link.
Please let me know if you have any questions or comments.
Thanks.
Necdet
Raj Sharma wrote:
I have some concern with
the way in which co-existence of Single Transit Buffer (STB) MAC and
Dual Transit Buffer (DTB) MACs on the same ring has been approached in
draft 0. I thought I voice my concerns to the working group on the
reflector to enable some dialog in resolving this concern while I also
file my comments.
I think the best place to
start would be at Clause 9.3, page 70, lines 3 and 4 which is: "If a ring consists of mixed RPR MACs
(single and dual transit buffer nodes), the fairness scheme will
needto interact without
disadvantaging any other node on the ring."
First disadvantage stems from the special accommodations to be
made in the DTB MACs to support performance requirements while using
STB MAC at other nodes. This requirement is stipulated further down in
the same Clause 9.3, page 70, lines 11 through 13. This stipulates that DTB MAC requires a rate shaper to throttle
ring outgoing rate to no more than 95% of the link rate. The only way
a loss-less MAC (as stipulated in 5.3.2, page 33, line 41) can do this
is to buffer frames when instantaneous rates exceed 95%. Further, if
such traffic shaper is classless than HP priority traffic could be
subjected to further buffering in this traffic shaper leading to
contradiction of clause 3.1, which requires HP traffic to have no more
transit delay than one frame-time through transit nodes.In other words defining a RPR standard
to accommodate STB MAC is not free of cost in terms of implementation and complexity
in the standard.
Raj
Colleagues,Draft
0.1 has been up on the RPR web for a week now, and I have yet to see
any significantdialog on the
issues that have been outlined in the draft by the editors. (I also
have notreceived any formal
comments from RPR WG members.) Please note that there is
onlyabout a week left to go in
the comment period, and about ten days to the meeting, so
Istrongly urge all concerned
parties to start their comments about these issues now.Best
regards,- Tom AlexanderChief Editor, RPR
WG
|