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