RE: Traffic characteristics
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
**********************************************************************