Re: [RPRWG] Simulations vs. worst case analysis
Dear Khaled,
I really appreciate your comments regarding simulations.
I should have said "I'm not superstitious about simulation"
in my last statement.
Simulation will provide some useful guidance if meaningful
modeling is done "right", otherwise it could be dangerously
misleading. To make it "right" in RPR case could be very
difficult and controversial, in that sense I really admire your
capability and courage to take the lead in the task.
In some cases, market reality concern about deterministic
behavior more than statistical behavior.
Best Regards,
William Dai
----- Original Message -----
From: "Khaled Amer" <khaledamer@xxxxxxx>
To: "William Dai" <wdai@xxxxxxxxxxxx>; <stds-802-17@xxxxxxxx>
Sent: Wednesday, April 25, 2001 7:51 AM
Subject: Re: [RPRWG] Simulations vs. worst case analysis
> William,
>
> I'd like to respond to the statement you made:
>
> > I'm not a simulation believer (although I used to be in that field), ...
>
> Needless to say, I AM a believer, since that's what I (and my company)
does
> for a living!
>
> Of course, this is not the forum to discuss (or argue about this).
However,
> we have so many issues that need to be resolved by simulation, to the
extent
> that we have an adhoc group for looking into that. With that in mind, I
felt
> it would be appropriate to make a couple of comments here. Of course, I
can
> make this a very long list of the benefits of simulations, but will make
it
> a very short one instead with just a few points that may be useful in this
> context.
>
> - As current and future computer network products (hardware and software)
> get more complex, we need modeling to get a good understanding of how
> they behave. The increasing complexity results in various components of
the
> system interacting in this complex environment in a way that is difficult
to
> get a complete grasp on understanding, and making sure that all the
> implications have been covered and thought of properly. Performance
analysis
> through modeling and simulation provides a practical way to optimize the
> architectures and proposed standards. Just worst case analysis doesn't
> necessarily provide enough information.
>
> - It also enables examining optimal architectural and design tradeoffs and
> compromises, performing "what-if" analysis quickly and cost
> effectively, without the need for prototyping, as well as estimating
> essentially any performance metric of interest. This is invaluable for
> identifying and solving performance problems that would surface otherwise
> later in the design or standardization process.
>
> - If all you really want is to calculate the worst case, you can do it
> using back-of-the-envelope calculations and/or a spreadsheet. However,
this
> would provide only that (i.e. worst case effects). You may or may not want
> to design for the absolute worst case, and you may have several solutions
> that meet the requirements for the worst case scenarios, but have very
> different statistical characteristics that should be taken into
> consideration. Also, maybe some statistical results would demonstrate
> whether it's necessary to design for the worst case. That's why I always
> suggest in the performance adhoc and to out clients (for example) that we
go
> for 99% or 99.9 percentiles of the delay as a way of quantifying jitter.
>
> - There may be other subtle effects that simulation can catch which may be
> hard to visualize by just doing some calculations. Things like effects of
> late feedback for congestion/admission control, potential instability or
> oscillations, evaluating the effects of various algorithms, tradeoffs and
> several priority classes when you have zillions of flows, with certain
> packet size distributions, interarrival times that are statistically
> distributed (or measured) ... and ... on and on and on ....
>
> - Sometimes, we can be interested not only in the worst case, but
> statistically how various solutions compare, and which tradeoffs word
better
> statistically. This is very possible with the help of simulations, and may
> be quite hard to quantify otherwise ... well ... unless we make the
analysis
> of that specific problem the topic of a 2 year research program leading to
a
> Ph.D, and do the same for all the issues we want to look into!
>
> Hope that you and others on the list find this short list to be useful.
> Would be glad to discuss any of the items in more detail if desired.
> (Of course, unless this is a topic of general interest to everybody, I
would
> suggest that we take it offline).
>
> Thanks.
>
> Khaled Amer
> President, AmerNet Inc.
> Architecture Analysis and Performance Modeling Specialists
> Address: 13711 Solitaire Way, Irvine, CA 92620
> Phone: (949)552-1114 Fax: (949)552-1116
> e-mail: khaledamer@xxxxxxx
> Web: www.performancemodeling.com
>
>
>
> ----- Original Message -----
> From: William Dai <wdai@xxxxxxxxxxxx>
> To: <stds-802-17@xxxxxxxx>
> Sent: Thursday, April 19, 2001 12:18 PM
> Subject: Re: [RPRWG] More comments on preemption
>
>
> >
> > Leon,
> >
> > Simulation may or may not catch the worst case situation. There are 128
> > nodes in your simulation model, the sheer number of nodes which makes
> > it look like the "toughest" you can get. While I believe it is good to
> > evaluate
> > the delay, but it make the jitter evaluation more difficult. Why ?
because
> > the
> > the probability of getting minimum delay (packet pass through 127 nodes
> > without being blocked by Jumbo frame insertion) and the probability of
> > getting maximum delay (packet pass through 127 nodes and being blocked
> > by Jumbo frame insertion at every node) diminish quickly as the number
of
> > nodes increases.
> >
> > Secondly, assume we're comparing a 100Mbps traffic flow going through
> > 1G ring vs. 10G ring with the same number of nodes and same traffic
> > generation models, AND on the other end of the anti-jitter buffer,
traffic
> > will be extracted out at 100Mbps for the same flow. In theory, the size
> > of the anti-jitter buffer and the delay caused by the anti-buffer should
> be
> > the SAME. It should not be a surprise because 10G ring is only 10 times
> > wider than 1G ring, not 10 times faster for the 100Mbps traffic flow.
> >
> > I'm not a simulation believer (although I used to be in that field), but
I
> > do
> > respect those people who is doing that. It is just a tool used by
PEOPLE.
> >
> >
> > Best regards
> >
> > William Dai
> >
> >
> > ----- Original Message -----
> > From: "Leon Bruckman" <leonb@xxxxxxxxxxxxx>
> > To: "'William Dai'" <wdai@xxxxxxxxxxxx>; <stds-802-17@xxxxxxxx>
> > Sent: Thursday, April 19, 2001 4:54 AM
> > Subject: RE: [RPRWG] More comments on preemption
> >
> >
> > > William,
> > > Actually we are concerned about jitter. We even presented some results
> > > during the January meeting (Gal Mor), you can see in the slides the
> > general
> > > assumptions made.
> > > Further simulations that we did indicate that for 128 nodes rings
> > operating
> > > at 1G with jumbo frames, the added delay caused by the jitter
absorption
> > > buffer is bounded to 6 msec. For 10G rings it is bounded to 1 msec. It
> is
> > > not ignorable, but it is still low. Note that the ring tested was 128
> > nodes,
> > > I believe that jitter and delay sensitive services will be provided
over
> > > rings with much less nodes (SONET limits the number of nodes to 20).
> > > You could argue that for lower rates the impact will be more
> significant,
> > I
> > > agree, but again I don't think that jitter and delay sensitive
services
> > will
> > > be provided in low rate rings with many nodes.
> > >
> > > Leon
> > >
> > > -----Original Message-----
> > > From: William Dai [mailto:wdai@xxxxxxxxxxxx]
> > > Sent: Wednesday, April 18, 2001 11:03 PM
> > > To: stds-802-17@xxxxxxxx
> > > Subject: Re: [RPRWG] More comments on preemption
> > >
> > >
> > >
> > > For those who only concern about current market reality,
> > > please ignore the following. Otherwise, please read on.
> > >
> > > During the preemption discussion, the most dominating
> > > factor people use againt preemption is that "under high
> > > speed condition, the worst case delay increase due to
> > > Jumbo frame is ignorable".
> > >
> > > However, does anybody concern about JITTER and the
> > > size requirement of the anti-jitter buffer at the receiving
> > > end terminal of the RPR (although the anti-jiiter buffer may
> > > not be required on the RPR node). For those who care,
> > > let me remind you the fact that the size of the anti-jitter
> > > buffer will increase along with JITTER, which results in
> > > further more delay. By looking at the percentage of increase,
> > > I'm not sure whether the word "ignorable" can be easily used
> > > here.
> > >
> > > One more point, I'm a cut-through advocate, not just for the
> > > gain on the delay factor, but mainly for the gain on the jitter
> > > factor. But for those cut-through advocates who are STRONGLY
> > > against preemption, I would ask the question: How can we
> > > justify the sacrifice of the hop-by-hop error checking capability
> > > in favor of "ignorable" gains on the delay and jitter by supporting
> > > the cut-through capability?
> > >
> > >
> > > Best Regards
> > >
> > > William Dai
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>
>
>
>
>
>
>