RE: [RPRWG] Complete RPR/Java model for all three proposals
Hi Pinar,
We should have the updated model ready early next week.
Thank you for your interest.
Komal
-----Original Message-----
From: Pinar Yilmaz [mailto:pinar@xxxxxxxxx]
Sent: Friday, January 04, 2002 1:42 PM
To: Adisak Mekkittikul
Cc: Khaled Amer; Stein Gjessing; stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] Complete RPR/Java model for all three proposals
Hi Adisak,
On a related note, in November meeting, it was communicated that
the models available at the following link:
http://grouper.ieee.org/groups/802/17/member/VoQ_release.zip
had an implementation problem and could not be used to study
aspects of the fairness algorithm.
Is there a plan to replace them with an updated version?
Pinar
Siamack Ayandeh wrote:
>
> Bob,
>
> I think the key word is "break" as you wrote in your earlier note:
> > The second class are those cases that could "break" the standard, i.e.
> reduce its performance
> > below acceptable limits.
>
> What I am suggesting is that there are many ways for a network to break:
> backhoes, component failures, software glitches, miss configuration etc...
By
> knowing the likelihood of occurrence of a pathological traffic scenario we
can
> weigh its significance along with all the other modes of failure.
>
> When it comes to evaluating the results of stress testing the proposed
transit
> path algorithms, we will be faced with a decision tree, and can not avoid
> attaching weights to any evaluation criteria that we use. IMHO: an
algorithm
> which is superior almost all the time and has a pathology that may occur
with
> say order of E-18 is preferable to a mediocre algorithm with no currently
known
> pathologies.
>
> As far as the marketing of RPR is concerned, I am no expert here. However
it
> seems to me that a "break" is a break and has to be seen in the context of
all
> likely failures.
>
> Regards, Siamack
>
> RDLove wrote:
>
> > Siamack and Adisak, you both make good points. I believe I have a
slightly
> > different point of view indicating a further area where we all need to
be
> > careful. When defining how RPR works, it would be far better to have an
> > algorithm that does not have holes in it that need to be explained away.
As
> > an example look at the way IEEE 802.3 has consistently treated
performance
> > issues, such as distance limitations and maximum frame size. The
criteria
> > they have always used is that their technology must work for the
absolutely
> > worst case. Any engineer can argue from a technical point of view that
this
> > approach is too conservative. However, from a marketing point of view
each
> > weakness that needs to be explained with probabilities is a significant
> > source of F.U.D. (Fear Uncertainty and Doubt) that can lead to decreased
> > acceptance of our technology. I strongly believe that we should attempt
to
> > find a solution that has NO fundamental weaknesses, even if the
likelihood
> > of exercising that weakness is small. Only if we can't achieve the
above
> > objective should we consider solutions that require explanations as to
why
> > the technology's fundamental weaknesses are really OK.
> >
> > If we expect RPR to be a huge success, then we can expect all present
> > implementations to represent only a tiny fraction of RPR's market
> > penetration. In addition, the range of applications addressed today, is
> > also likely to be only a small fraction of the applications that will
> > eventually be handled. Therefore, failure to see field problems today
is
> > not relevant to proving that similar algorithms are sufficiently robust.
> >
> > 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: "Adisak Mekkittikul" <adisak@xxxxxxxxxxxxxx>
> > To: "'Siamack Ayandeh'" <sayandeh@xxxxxxxxxx>; "RDLove"
<rdlove@xxxxxxxxx>
> > Cc: "Khaled Amer" <amer@xxxxxxxxxxx>; "Stein Gjessing"
<steing@xxxxxxxxx>;
> > <stds-802-17@xxxxxxxx>
> > Sent: Wednesday, December 26, 2001 2:10 PM
> > Subject: RE: [RPRWG] Complete RPR/Java model for all three proposals
> >
> > >
> > > Siamack,
> > >
> > >
> > > I agree that it might be necessary to weight the problems we might
find.
> > > But at this phase of the standard development, I think we should be
> > > more critical at finding the performance weaknesses of all proposed
> > > algorithms.
> > >
> > > We need have all necessary data points to make a good decision. So far
> > > the performance evaluation has been more of marketing talk. It's
> > > mostly about how well this algorithm and that algorithm perform.
> > > That is not good for our selection criteria.
> > >
> > > We need to do more of stress testing to determine the limitation of
each
> > > proposed algorithm. There are a few basic tests we can start with:
> > >
> > > 1. Control loop convergence test
> > > 2. Fairness index
> > > 3. Loss and delay
> > > 4. Link Utilization
> > > 5. Spatial reuse
> > >
> > >
> > > Although coming up with good stressful scenarios to test the above
metrics
> > > can be hard, I think it's achievable in a short time frame if we get
> > people
> > > to contribute the "worst" traffic pattern that they know of.
> > >
> > > What do you say folks? Any volunteer to compile the list?
> > >
> > >
> > >
> > > Best Regards,
> > > Adisak
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Siamack Ayandeh [mailto:sayandeh@xxxxxxxxxx]
> > > Sent: Friday, December 21, 2001 8:18 AM
> > > To: RDLove
> > > Cc: Amer, Khaled; Stein Gjessing; stds-802-17@xxxxxxxx
> > > Subject: Re: [RPRWG] Complete RPR/Java model for all three proposals
> > >
> > >
> > > Bob,
> > >
> > > Thanks for sharing your insightful experience re pathological traffic
> > > scenarios.
> > > In response to your suggestion: "One of the criteria we should have
in
> > > choosing
> > > an algorithm is that the
> > > worst case pattern simulations exceed some minimum threshold."
> > >
> > > I would like to add that the likelihood of occurrence of such traffic
> > > scenarios
> > > is also of utmost importance. Usually such pathological traffic
patterns
> > > are
> > > rare events, i.e. far towards the tail of the distribution. Having
this
> > > likelihood would put the scenario in perspective and also determine
the
> > > required
> > > urgency of a resolution. I think it is important to attach this
"weight"
> > to
> > > the
> > > criteria when it comes to selection of alternative algorithms.
> > >
> > > Regards, Siamack
> > >
> > > RDLove wrote:
> > >
> > > > 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
> > > > >
> > > > >
> > > > >