Re: [RPRWG] Complete RPR/Java model for all three proposals
To: 802.17 Reflector, and Stein Gjessing
Stein, Khaled, and all simulation experts, this email focuses on how we
choose
traffic simulation patterns to run. Drawing on my experience in 802.5 Token
Ring Working Group, I believe there are two classes of simulation patterns
that are critical. The first class, are the patterns that push the
boundaries of important classes of expected traffic. I expect that the
output of the performance committee focused on this case. The second class
are
those cases that could "break" the standard, i.e. reduce its performance
below acceptable limits. I have not seen much focus on this second class of
patterns, yet that is the class of patterns that could jeopardize the
success of RPR.
In the 802.5 Token Ring Working Group we discovered a "killer frame" that
caused a buffer to overflow. For a couple of meetings, addressing and
solving the "killer frame" problem consumed the working group. We were also
very concerned about the press talking about token ring having a "killer
frame" problem, and what that would do to token ring sales. The problem was
finally solved by significantly increasing the required buffer size, so that
no "killer frame" existed.
Early coaxial Ethernet, which used "vampire connectors" had its equivalent
of the "killer frame". It turned out that if you inserted vampire connector
taps into the coaxial cable at a spacing that was a simple harmonic of the
fundamental frequency, standing waves were created that caused reception
errors. That problem was fixed by marking the coaxial cable periodically
where you were allowed to tap into it. The markings were spaced a distance
that was not a simple harmonic of the fundamental frequency, so that large
standing waves would not be created.
RPR must allocate bandwidth based on an algorithm that by its nature cannot
react instantaneously to the traffic requirements. The feedback, or
feedforward nature of any algorithm will cause a response that is analogous
to a circuit designed with a pole. The circuit has a resonant frequency,
"f" and a "Q" associated with it. Depending on the parameters chosen, f and
Q could be changed. If the Q is high, then the circuit response to an
excitation near frequency f would be dramatically different from the
response to other excitations.
By undersanding the physics of the feedback or feedforward algorithm we are
proposing, we should be able to create the traffic patterns that excite our
models at their point of resonance. The requirement is that the model does
not break under that excitation. In other words, the performance does not
drop below acceptable parameters under "worst case" traffic.
If a problem is found, there are two ways of addressing it. One is to change
the point of resonance. This is a poor change, since it only means that the
present worst case pattern doesn't cause the problem, but a new pattern will
uncover the problem again, as bad as it always was.
The other change is to change the Q of the model such that the degradation
in performance of the model at its point of resonance is still within
acceptable bounds.
Clearly, each model will have its own "worst case patterns". Hopefully,
those
groups forwarding proposals will understand their algorithms well enough
to be able to supply the worst case simulation patterns for that model.
One of the criteria we should have in choosing an algorithm is that the
worst case pattern simulations exceed some minimum threshold.
I believe that for RPR to be successful we must require acceptable
performance levels for worst case patterns. I assume that whatever
algorithms are incorporated into our draft in January will be thoroughly
simulated before the March meeting to be sure there are no "killer patterns"
for RPR. I would be pleased to hear feedback from the simulation experts
on the need to include this criteria as one of the bases for adopting a
solution.
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 -----
From: "Stein Gjessing" <steing@xxxxxxxxx>
To: <stds-802-17@xxxxxxxx>
Sent: Tuesday, November 27, 2001 8:54 AM
Subject: [RPRWG] Complete RPR/Java model for all three proposals
>
> All,
>
> I will try to implement all three proposals:
>
> Alladin,
> DVJ,
> Gandalf
>
> in my RPR/Java-simulator and get some simple traffic
> scenarios running before the January meeting.
>
> I have the early November drafts of all these proposals as they are
> posted on the web site. However, I need working drafts of more
> details of the fairness/flow control algorithm parts of these
> proposals. I talked to some of you during the Austin meeting
> and you said you could send me material that would help me in
> my Java implementation effort. So please do that now.
>
> Please make specifications as precise and algorithmic (step by
> step description on what to do in different cases) as possible.
>
> All Java code (that is all the RPR/Java models including the simulator
> code itself) will be available for everyone. If the material you send
> me contains confidential information (not related to the specific
> fairness/flow control algorithm), I can treat that material
> confidentially.
>
> I also suggest you send me traffic scenario proposals
> (e.g. two for each of the Alladin, DVJ and Gandalf proposals)
> that you think I should run.
>
> I hope to be able to do this during December, but depending
> on how difficult this will be, as well as what else I have
> to do in my job, I can of course not promise anything.
>
> Stein
>
>
>