RE: Traffic characteristics
I
think RPR should support other traffic as well, but it should at least address
TCP/IP. I agree with BJ that self similar models and trace driven
simulations are not sufficient to evaluate PRP protocol performance. We
should use real TCP/IP sources in simulations. Traces or models don't capture
the interactive flow control of TCP. RPR protocol may very sensitive
to this interactivity.
We can
look at results from sites like www.caida.org to determine the packet size
distribution, flow length, number of tcp flows, number of UDP flows, type of
applications etc on the backbone. These parameters should be used to
simulate real TCP sources.
-Sanjay K. Agrawal
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
Salman Phone:
202-364-4700x2297
Manager, Market
Research Mobile:
202-427-3319
OPNET Technologies,
Inc. E-mail:
tsalman@xxxxxxxxx
3400 International Drive,
NW Web: www.opnet.com
Washington,
DC
20008
**********************************************************************