Re: [RPRWG] Complete RPR/Java model for all three proposals
Happy new year Siamack. I appreciate your airing your point of view on this
issue, and getting right back into it after the holiday break. I don't
think that our positions are that far apart. Our words are probably further
apart than our positions are. I would like to think about how to square
this circle and address it again at the January interim meeting where we are
sure to get lots of input besides our two voices. Time, and one-on-one
discussions are likely to produce a set of words we can both sign up to.
Hopefully, other will be able to develop a consensus position then.
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: "Siamack Ayandeh" <sayandeh@xxxxxxxxxx>
To: "RDLove" <rdlove@xxxxxxxxx>
Cc: "Adisak Mekkittikul" <adisak@xxxxxxxxxxxxxx>; "Khaled Amer"
<amer@xxxxxxxxxxx>; "Stein Gjessing" <steing@xxxxxxxxx>;
<stds-802-17@xxxxxxxx>
Sent: Wednesday, January 02, 2002 3:33 PM
Subject: Re: [RPRWG] Complete RPR/Java model for all three proposals
> 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
> > > > >
> > > > >
> > > > >
>