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