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
> >
> >
> >
> >
>
>