What are the key applications do you have in mind for RPR? I'm not
interested in solving world hunger!
... Harry
"Byoung-Joon (BJ) Lee" wrote:
Raj,
Thanks for the clarification. It seems that my previous email
may have given
the wrong impression that RPR should only support IP services by emphasizing
the TCP/IP traffic modeling.
It would be great if there could be a slot assigned at the next week's
meeting
for more discussions on this topic (e.g., RPR vs Gigabit Ethernet,
how to
support services without requiring IP functionality, pt2pt ethernet
over WDM on a
physical ring, what additional value we can bring with RPR, etc).
Cheers,
BJ
At 01:16 PM 08/24/2000 -0700, Raj Sharma wrote:
BJ
and RPRSGers,
I perhaps come
across garbled in my previous email.
I really dont
mean to imply to standardize services.
What my concern
is that we have to account for
applications
where Data, Voice and Video that might
get be carried
over this protocol without requiring
IP layer functionality.
Each of these services has a
specific traffic
pattern and boundary conditions. This must
be our top level
requirement. Then we can drill down into each
of these broad
service categories and get more granular.
My concern with
RPR is that the feedback I am getting from
our customer
base. They feel that if RPR deals primarily
with IP traffic
and they are expected to figure out the utopian
path of voice
or video over IP then this is a far stretch
of an imagination
from the reality that exists out there.
Hence, they
are interested in provisioning more than IP
traffic over
a layer 2 technology. If RPR does not make
that diffrentiation
than why would they not use point-to-point
ethernet over
DWDM on a physical ring? If RPR is just an
evolution of
POS we can pretty much pack our bags and go
home.
Further, from
a service perspective it is the simple provisioning
paradigm that
is of great interest to them. Packet switch based
technology provides
a simple "LAN-like" provisioning paradigm.
However, this
can only become a true benefit if it applies to all services
and not just
to one service.
I urge everyone
to take a look at how gigabit ethernet is a viable
metro solution
and what additional value we can bring with RPR.
The traditional
problem that buffer insertion rings have faced
in the past
is the compelexity of administering fairness or
deliberate unfairness
over the ring in store-forward, multi-hop
network. If
all we are worried is about TCP/IP traffic than
point-to-point
ethernet resolves that very elegantly. BTW,
point-to-point
ethernet can also use a physical ring deployment.
There has been
a lot of talk of the speed of protection
switching. Realistically,
if you are only carrying TCP/IP
traffic than
you will get a glazed look in these customers
when sub 50
millisecond protection switching is touted.
The reason for
this is fundamentally, protection mechanism
as to at the
same layer the service gets provisioned. For SONET
it made sense
because all services were provisioned over
SONET.
This is another reason why we must understand
what services
(other than IP) will RPR provide to make its
protection mechanism
more meaningfull than the lack of it
in Ethernet.
This is an issue
for RPR in general to gain acceptance as
a serious upcoming
paradigm. We must clearly make a
difference over
Ethernet or E-over-SONET, etc.
comments?
-
-----Original Message-----
-
From: Byoung-Joon (BJ)
Lee [mailto:bjlee@xxxxxxxxx]
-
Sent: Thursday, August 24, 2000 12:36 PM
-
To: Taylor Salman
-
Cc: Raj Sharma; 'Khaled Amer'; Reflector RPRSG; Charles Barry; Atul Shinde
-
Subject: RE: Traffic characteristics
-
Hi,
-
Among many web sites, the following two could be useful for traffic traces
-
and packet size distributions:
-
traffic traces:
-
http://www.acm.org/sigcomm/ITA/
-
packet size distribution:
-
http://oceana.nlanr.net/NA/Learn/packetsizes.html
-
However, the problem with the trace-driven or self-similar traffic simulation
is that
-
we do not explicitly model the dynamic nature of the TCP/IP traffic reacting
to
-
congestion. Unless for the one-way UDP or background traffic modeling,
such
-
aggregate traffic characterization may not be useful.
-
As for the Raj's argument for the service modeling, I would say we are
expanding
-
the scope too much at this time? It could be argued that we are not
defining or
-
standardizing the "services"?
-
Cheers,
-
BJ
-
At 10:08 AM 08/24/2000 -0400, Taylor Salman wrote:
-
Expanding on some of these points. Yes, self-similar traffic is a
good way to go to simulate large amounts of IP traffic. Self-similar
traffic models are already available that allow you to bypass modelling
of the TCP/IP stack (although, I believe that BJ has some concerns in this
regard). Bo Ryu from Hughes Research Labs has done extensive research
in this area. I can put people in touch with him if they are interested.
-
In my opinion, there should be a series of scenarios that test different
aspects of the system. Perhaps, self-similar traffic is one test
for the performance of TCP/IP traffic. It is also possible to get
models of live traffic to play over the models, as well as, standard application
traffic models such as HTTP, FTP, e-mail, video, voice, etc. I agree
with Raj in that a determination of typical traffic mixes needs to be made,
and different scenarios constructed to model these mixes. My opinion
does differ from Raj, however, in that I think pathological cases can provide
as much insight into system behavior as typical cases and scenarios should
be constructed for both, particularly for a protocol where one of the main
goals is resiliency in the face of link failure.
-
Taylor
-
At 06:25 PM 8/23/00 -0700, Raj Sharma wrote:
-
You could use self
similar traffic patterns.
-
There is quite a bit of publication on such traffic
-
patterns. William Stallings had a book that spent an entire
-
section on it. (High performance networks ---- or something
-
like that)
-
-
However, isnt this
more of a "regression" parameter
-
rather than "main" parameters we want to test our
-
Layer 2 protocol against. Much of the issue that
-
we need to sort out for these main parameters
-
are the ranges of value. Cooking up these values must
-
make practical sense and they cannot be pathological
-
cases to test boundary conditions.
-
-
Perhaps what we
need to do is to move one level up
-
and ask ourselves what services will get provisioned
-
over (layer 2) RPR and hence what are the main parameters.
-
Remember you cant design a layer 2 protocol only
-
based on a specific layer 3 protocol. If that is the case, I rather
-
do MPLS switching over rings.
-
-
Thoughts?
-
-
-----Original Message-----
-
From: Khaled Amer [mailto:khaledamer@xxxxxxx]
-
Sent: Thursday, August 24, 2000 3:23
AM
-
To: Reflector RPRSG
-
Subject: Traffic characteristics
-
RPR'ers,
-
I raised this question about 3 weeks ago
and got the familiar underwhelming response!
-
Several people indicated availability
of traffic patterns that were taken off the Internet or other networking
environments that would be useful for us to use in the simulations. In
my mind, we need things like packet size distributions, interarrival times,
burstiness, application and protocol distributions, and any other relevant
characteristics of network traffics that we may want to consider in the
simulations.
-
Does anyone have such information that
they can share with us in the meeting next week?
-
-
Khaled Amer
-
President, AmerNet
-
Architecture Analysis and Performance
Modeling Specialists
-
Phone: (949)552-1114
13711 Solitaire Way, Irvine, CA 92620
-
Fax: (949)552-1116
e-mail: khaledamer@xxxxxxx
**********************************************************************
P. Taylor SalmanPhone: 202-364-4700x2297
Manager, Market ResearchMobile: 202-427-3319
OPNET Technologies, Inc.E-mail: tsalman@xxxxxxxxx
3400 International Drive, NWWeb: www.opnet.com
Washington, DC 20008
**********************************************************************
--
Harry Peng
------------------------------------------------------------------
Dept: 1E11
Email: hpeng@xxxxxxxxxxxxxxxxxx
ESN: 39-52277
Phone 613-765-2277
Fax: 613-768-4904
Web: http://skywww/~hpeng/
-------------------------------------------------------------------
|