Re: RPR perf: Regarding the vote
Offer,
Thanks for the input.
You're right. That's why I carefully worded it as a straw poll vote.
You're also right about cautioning about the need to carefully define what
needs to be done and what is meant by terms like fairness, ...etc.
Since we need so much more time to handle these issues, we formed a separate
adhoc for that activity with all the experts invited to participate and help
out with this effort. Only getting an hour or two as part of the mainstream
discussion won't cut it. Also, seeing that we have so much more to do, we
had to postpone starting the simulation efforts till next meeting. In the
meantime, we hope to continue to hold productive, fruitful discussions on
the reflector so that we can make significant progress in March. Also, as I
indicated in January, I'm requesting that we get about 8 hours in March to
plow through all these issues after working on them as much as possible on
the reflector. Hopefully this will help us make good progress in March, and
also proceed properly to ensure that we're on the right track.
Your input is very welcome, and any other input is appreciated. This helps
make sure that we're on the right track.
Thanks again for the input.
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
----- Original Message -----
From: Offer Pazy <pazy@xxxxxxxxxxxxxxxxxx>
To: 'Khaled Amer' <khaledamer@xxxxxxx>; 'Donghui Xie' <dxie@xxxxxxxxx>
Cc: 'Reflector RPRSG' <stds-802-rprsg@xxxxxxxx>
Sent: Tuesday, January 30, 2001 6:19 PM
Subject: RE: RPR perf: Regarding the vote
> Hi all,
>
> I hate to be the "procedure" cup, but I have to remind everybody that we
are
> not in a position to take any "formal votes" yet. Also, we should not
treat
> previous SG decisions as binding and worry about "reopening" decisions.
The
> first time we can officially vote is in March. This is not just a
> theoretical issue or one which concerns the perf. ad-hoc only. I suspect
> that the performance work will take a significant amount of the time and
> resources of the entire WG and therefore the decision of what to do and
how
> much needs to be taken carefully.
>
> I realize that a lot of preparatory work is needed in order to bootstrap
the
> simulation work and the earlier we do it the better. On the other hand, we
> cannot let the simulation work shape the outcome of what the MAC will look
> like. I read a lot of references to fairness, congestion control, and
other
> features which 1) are far from being properly (and consensus-ly) defined,
> and 2) have not been formally voted as being part of the requirements.
>
> I plead for caution and patience. Trying to rush things will only hurt us
> later on in the process when consensus will be hard to achieve.
>
>
> Offer Pazy
> Sr. Product Manager
> Native Networks
> 15 Gonen St.
> Petah Tikva 49170
> Israel
> Tel: +972 3 921-0010 Ext. 229
> Fax: +972 3 921-0080
> pazy@xxxxxxxxxxxxxxxxxx <mailto:pazy@xxxxxxxxxxxxxxxxxx>
> http://www.nativenetworks.com
>
> The Native Way = Ethernet Simplicity + SONET Reliability
>
>
> -----Original Message-----
> From: owner-stds-802-rprsg@xxxxxxxx
[mailto:owner-stds-802-rprsg@xxxxxxxx]On
> Behalf Of Khaled Amer
> Sent: Tuesday, January 30, 2001 22:24
> 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
> >
>