Re: [RPRWG] Simulations vs. worst case analysis
Dear William,
Thanks for the nice words.
I'm glad to help.
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: amer@xxxxxxxxxxx
Web: www.performancemodeling.com
----- Original Message -----
From: William Dai <wdai@xxxxxxxxxxxx>
To: <stds-802-17@xxxxxxxx>
Sent: Wednesday, April 25, 2001 1:34 PM
Subject: 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>