----- Original Message -----
Sent: Tuesday, January 30, 2001 8:13
PM
Subject: RE: RPR perf: Regarding the
vote
Khaled,
I aggree with Offer. As we made our way, over a year, in
becoming a working
group in IEEE to define a MAC
we have picked up a lot of information
on various
approaches for a RPR based system. What stood out as wide
difference are system level issues like fairness and congestion
control
contrasted with how similar each of the
MAC header definition was.
The reality was that
each RPR system dealt with different services at the
box level.
What happened during the study
group phase was a testimony of
existence of a
common shared ring, multi-node, spatial reuse paradigm
by describing "system" level features of each type of box that
could sit
on an RPR ring. Now we are in the role
of defining a MAC. We need take the
value of this
education but move forward and go define the basic
element - the MAC.
Although, it is inconceivable of an RPR box without
features to
address congestion on the ring it is
not within the usual realm of MAC
definitions.
MAC's decide WHEN to put ANY packet GIVEN to it by the
system on its client interface on the INDICATED media interface and
not
necessarily decide WHICH packet. MAC's can
indicate to the client indicate when
it is ready
for the next packet giving the client the flexibility in either
deffering transmission or giving the MAC a certain type
of packet.
A MAC's role in a networking system is
to predictably deliver a packet given
on its
client interface to the physical layer. Both the assurance of
the packet being delivered accurately over the physical
layer and keeping a tab
on which MAC is putting
more or less traffic is usually not a MAC layer issue.
Some networking MACs made this their business and died a vey young
death on
their way to adoption (ATM's ABR). Hence
I view fairness on rings a system
level issue and
not a MAC issue. Further, we need an official position in the
working
group of this kind of jurisdictional issue
as Offer pointed out.
I agree, that one must define a MAC by understanding
common types of congestion and
fairness schemes
that exist. However, the actual definition of a particular
congestion or fairness scheme is to narrow, rigid and
will fail to provide
flexibility and
differentiation in products that adopt RPR as a technology.
It has been very intriguing to me that while you are
taking a straw (amended
words) poll on the type of
traffic (TCP or raw) I wonder if you will find
any
different answers than the rest of this world has already found in terms
of what types of congestion mechanisms work for
these types of end-to-end
flows when they travel
across a series switches. Even if you do find a different
flow control mechanism or congestion algorithm this would not give
RPR an edge
over ethernet switches in a ring since
at the MAC layer you will only be able
to control
aggregate flows (a combination of TCP and raw). It would be
instructional
for us to review how ethernet
decided to deal with this with the option of
using
pause frames (sort of an XON/XOFF scheme) in Ethernet. What algorithm
triggers a
PAUSE frame is certainly not part of
the Ethernet standard. The point I am making
is we must be able to focus ourselves to the MAC and not get side
tracked by
system level issues.
let us try to work what is relevant to MAC and not spend
time on developing a new
fairness alogirthm or a
congestion mechanisms - we will never get the standard
done in time to rally support in the industry that RPR is a
promising technology as seen
by steady progress
toward standardization by gaining confidence through the
widespread commonality
Raj Sharma
-----Original Message-----
From:
Khaled Amer [mailto:khaledamer@xxxxxxx]
Sent: Tuesday, January 30, 2001 7:01 PM
To: pazy@xxxxxxxxxxxxxxxxxx
Cc: 'Reflector
RPRSG'
Subject: 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
> >
>