|
Dear Khaled:
Good you highlighted the issue of whether congestion control and fairness
mechanisms should be included. Through emails Raj has been trying to highlight
the issue that congestion control and fairness mechanisms were never a
part of MAC layer to begin with. A MAC is supposed to do just what Raj
mentioned in his email. A MAC layer is only providing access for the packets
already given to it by the higher layers.
Consider traffic flow between A and C in the network below (only a single
ring segment is shown).
+-----+ +-----+
+-----+
| | X
| | Y
| |
- >---| A
|--------| B |-------| C +------->
| |
| |
| |
+-----+ +-----+
+-----+
Not all packets between the two nodes (A and C) would necessarily have
same priority and bandwidth allocation. The nodes may have reserved bandwidth
for a particular flow using RSVP or some other administrative means. Flows
are identified by layer 3 information.
Node B has no idea (and shouldn't have any idea) about what flows have
been allocated with what bandwidth reservations. The layer 3 protocols
at node B also participated in setting up a path and bandwidth from A to
C, as B is in the path A-B-C. Accordingly, B's queues and schedulers (note
that architecture of queues and schedulers is a local issue specific to
a node - these are never part of a protocol) come into action and direct
selected packet flows from X at input port to X at the output port. Since
there is an O-E-O conversion at nodes, all packets are taken off the link
X, directed to internal buffers (into different queues, if the node wishes
to), and then scheduled out on Y depending on flow characteristics. If
node B has allocated some of its own flow paths with higher bandwidth requirements,
it may decide to hold some of the packets coming from A for a longer time
to allow its own packets to travel. All of this is guided by layer 3. MAC
has no knowledge, and plays no role in deciding any of these decisions.
On a related issue of congestion - if node B notices that incoming packets
from A are way too many, the packets have no guaranteed reservations, and
node B needs to put forward its own packets with a higher priority or guaranteed
bandwidth, it will simply schedule its own packets into output queue on
interface Y. Packets from A are held off. Any node is completely at liberty
to shape its downstream traffic, parameters of which are always decided
by the system.
Regarding performance simulations for fairness/congestion - currently
we don't know what the MAC looks like, we're still debating what MAC should
contain, some of us are still thinking MAC should do all of the neat system-level
things. If simulations are required, we can get an 'approximate' picture
from other ring topologies for TCP/UDP and leave it at that for now, as
Bora suggested, and get going without "being side-tracked by system-level
issues". Without any additional parameter to consider for RPR (since we've
no idea what type of MAC it will be) there isn't any use in starting simulations
from scratch.
RPR, properly designed, would make the MAC layer transparent to upper
layer. I believe we should focus on addressing and outlining issues in
a "top-down" fashion. Different versions of Ethernet never disturbed IP
layer and other system issues, and RPR shouldn't behave any differently.
Another issue to keep in mind is that optical links are unidirectional
in nature. In the network diagram above, node B receives packets on X and
transmits on Y. Unlike CSMA/CD Ethernet, node B does not even have to contend
with link availability for transmitting packets on X while packets are
being received on X. All packets from X come to node B packet/system memory
in a 'dump' fashion. Then node B (using L3-guided methods) picks and chooses
which packets to send out on Y. The situation, as far as the MAC layer
is concerned, is extremely simple. All packets from node A go to exactly
one node - node B. While there could be multiple output links to choose
from for an incoming packet, there isn't a need for "selecting a node among
multiple nodes" at the input port. Going a bit further on this - the system
puts packets in an output buffer, and a MAC at the node B simply streams
the bytes out at the specified clock rate (just like any other optical
framer/PHY/Optics does). There is no bus contention to deal with.
We may then wonder, what is the function of RPR MAC? Let's discuss what
it is. This is important. This is what Raj refers to as "focusing on MAC
issues". Let's spend more time discussing MAC, rather than presuming that
MAC is well-known and done and starting work on simulations. Let's not
jump too far ahead and risk missing on fundamentals. Once the standard
is ready, the next challenge we have is to convince industry that RPR MAC
has really attractive features - to promote its widespread adoption.
To summarize, as far as fairness and congestion are concerned - these
are and have been system issues, systems always dealt with these, and let
us leave the systems to worry about these. For all these years, an Ethernet
MAC allowed development of all kinds of buffering and fairness mechanisms,
and never came in the way of developments in traffic management techniques.
The trend continues with GbE and 10GbE. We should do the same for RPR.
- Pankaj
Khaled Amer wrote:
Thank
you, Raj, for your response. As always, you are able to put a lot of very
useful info in context.I also agree with a lot of what Offer mentioned
as I mentioned in my previous note to the reflector. However,
I'm kind of puzzled by your paragraph that includes even a more puzzling
sentence:For example: 'Not be side tracked by system level issues'.
Is this telling us that we should not
look into congestion control and fairness mechanisms as part of the perf
adhoc efforts? I thought that this was one of the objectives that we were
shooting for as part of this effort. Do you have a different opinion here
that we should discuss related to this?
Thanks again.
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 -----
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
> >
>
|