| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi BJ,
As long as we choose common TCP model that is TCP RENO, agree on number of tcp flows and
the common max window size, and common file size for FTP application, we will have same model in any simulation scenario.
TCP implementations (RENO, TOhoe.. ) are open and widely accepted standards there should be common implementation on opnet and ns2. NS2 implementation of TCP stacks is widely accepted and verified. Van Jacobson himself (who invented and implemented TCP) has verified it. Opnet should have the similar implementation. It is not so important that we use the same traffic model but a correct and same traffic model that is use on Internet today.
We should have phased approach, where can start with something simple and unrealistic, but our simulations are meaningless if we don't simulate realistic protocols in the next phase as asserted by Adisak. Thanks Adisak!!
-Sanjay K. Agrawal
-----Original Message-----
From: BJ Lee [mailto:bjlee@xxxxxxxxxxxxxxxxxx]
Sent: Tuesday, January 30, 2001 11:25 AM
To: Khaled Amer; Reflector RPRSG
Subject: RPR perf: vote
- raw packets
If I may add to this discussion, I would suggest that we use "common
harness" (including the traffic generator) as Harry proposed in his slide.
TCP traffic modeling approach (soon to follow) will lead to a critical
question
of required # of TCP connections (tens of thousands, or more?), window
sizes, etc., necessitating common parameter calibrations. Performance with
explicit TCP traffic generator may also raise a question whether RED discard
at L3 need be modeled as well (if that is the case).
It has been observed that 3 out of 6 active participants are using Opnet,
and
one using ns2. Anyone out there did the TCP model calibration for fair
comparison between Opnet and ns2 TCP models? Having a common harness will
make performance analysis easier and less controversial.
Cheers,
BJ
-----Original Message-----
From: owner-stds-802-rprsg@xxxxxxxx
[mailto:owner-stds-802-rprsg@xxxxxxxx]On Behalf Of Khaled Amer
Sent: January 30, 2001 1:22 PM
To: Reflector RPRSG
Subject: Re: RPR perf: My thoughts
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