RPR perf: vote
I lean toward
- raw packets
for the step#1.
Adisak
-----Original Message-----
From: Khaled Amer [mailto:khaledamer@xxxxxxx]
Sent: Tuesday, January 30, 2001 12:24 PM
To: Donghui Xie
Cc: Reflector RPRSG
Subject: Re: RPR perf: Regarding the vote
All,
Please put:
RPR perf: vote
in the e-mail subject field.
and select one of the options:
- TCP
- raw packets
- Abstain
This will help me a lot.
You can add comments following that if you want.
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: Donghui Xie <dxie@xxxxxxxxx>
To: Khaled Amer <khaledamer@xxxxxxx>
Cc: Reflector RPRSG <stds-802-rprsg@xxxxxxxx>
Sent: Tuesday, January 30, 2001 11:02 AM
Subject: Re: RPR perf: My thoughts
>
> Hi All,
>
> TCP traffic performance over RPR is definitely the most important part of
> RPR MAC evaluation. However, I don't think TCP traffic performance over
RPR
> should be the first step. What we need here is to establish a clean and
> simplistic RPR MAC performance baseline in a timely manner. TCP network
> behavior can be pathological due to many reasons ranging from application,
> RTT estimation factors to TCP simulation models. By just specifying a
Tahoe
> or any other flavor of TCP would not bring consensus to TCP traffic
> generation specification any time sooner.
>
> Using raw UDP traffic will never produce a definitive performance
> conclusion for RRP MAC, but it does allow us to focus on RPR MAC
> performance baseline. RPR MAC performance evaluation should be a
> progressive advancing process, from simple to complex and from partial to
> complete. Any shortcut may well be counter productive and time consuming.
>
> I support raw UDP traffic as step #1 simulation.
>
> Best Regards,
> Donghui Xie
>
>
> At 10:22 AM 1/30/01 -0800, Khaled Amer wrote:
>
> >All,
> >
> >I'd like to suggest that we avoid involving ourselves in heavy duty
traffic
> >characterization problems (whether traffic is self-similar or not, and
all
> >of that). As we know, this is an active area of research, and we can spin
> >our wheels trying to resolve this. There are so many schools of thought
on
> >this. I don't believe that it will have a dramatic effect on what we're
> >trying to accomplish here.
> >
> >Now, on another related point, in August, we had arrived to the
conclusion
> >that we'll start step#1 of the simulations using raw traffic with no
> >protocols involved, and make the runs with TCP and UDP (and mixes) as
step
> >#2. We voted on this and agreed among ourselves to do so. I looked at my
> >records and found that the Luminous guys didn't attend that meeting when
we
> >made that decision. Apparently they had to leave.
> >
> >I'm seeing that there are a lot of discussions on the reflector going
back
> >to this point. Even though I don't want to take a step back on decisions
> >that were already made and voted on, so that we continue to make
progress, I
> >guess we need to reopen this one and make a decision again.
> >
> >I'll open it up for an electronic straw poll vote.
> >
> >Here is what we'll be voting on:
> >
> >As the first step in running the simulations, we should use traffic
streams
> >that:
> >1) use TCP streams as step #1 in the simulations, and not just raw data.
Raw
> >data and other protocols (like UDP) will follow immediately afterwards as
> >step #2.
> >2) use raw packets with no protocols as step #1 in the simulations. TCP
and
> >UDP protocols (as well as mixes) will follow immediately afterwards as
step
> >#2.
> >
> >Please vote by selecting one of the following choices:
> >
> >- TCP
> >- raw packets
> >- Abstain
> >
> >Please remember that this vote is just for the first set of simulations.
> >Just trying to narrow down the number of runs to a manageable subset for
the
> >first batch of simulations. We all agree that we're going to be doing all
of
> >the other steps in the presentation that I gave as step #2.
> >
> >Please cast your vote by Friday (2/1). I'll post the results that evening
or
> >over the weekend.
> >
> >Please put:
> > RPR perf: vote
> >in the e-mail subject field.
> >
> >In either case, we're going to decide on some simple traffic input
process
> >that we can use as a starting point too. We can get into more elaborate
ones
> >later, if we see that it would be appropriate and productive for this
group
> >to use (and if it doesn't get us all into a black hole!)
> >
> >Waiting for your vote.
> >Best regards.
> >
> >Khaled Amer
> >Chairman, RPR Performance Modeling adhoc Committee
> >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
>