RE: RPR perf: My thoughts
Some suggestions:
A number of people are planning on simulating these implementations
within OPNET. There are two potential options for the modeling of
this traffic:
1) Use randomly generated application traffic flowing over the
detailed TCP/IP model.
2) Use the self-similar traffic generator in OPNET, skip the TCP/IP
model, and send the traffic directly to the RPR model.
It might even be an interesting exercise to model it both ways to and
analyze the difference in the results... assuming anyone has the
time... ;-)
Taylor
At 04:25 PM 1/26/01 -0800, Sanjay Agrawal wrote:
Convergence
may or may not be the issues, but we need to simulate real TCP traffic as
opposed to traffic from traces.
Our objective in these simulations is show how TCP flow control mechanism
interacts with the competing approaches of RPR mac fairness flow control
mechanism. Traces will dump traffic on the RPR mac regardless of what RPR
mac flow control does. On the other hand TCP sources may never come out
of their slow start to utilize the available bandwidth from RPR.
Our objective is to make sure
we design RPR mac which doesn't interfere with upper level flow control
mechanisms like TCP or any other protocol that implements flow
control.
Thus analysis based real TCP
sources is must at some point for us to compare solutions.
For a common reference, we can
decide the number of sources and the type of TCP (any of the RENO, TAHOE,
VEGAS TCP implementations).
-Sanjay K. Agrawal
Luminous Networks
- -----Original Message-----
- From: Shahid Akhtar
[mailto:sakhtartx@xxxxxxxx]
- Sent: Thursday, January 25, 2001 2:51 PM
- To: Harry Peng; khaledamer@xxxxxxx
- Cc: Changcheng Huang (E-mail); Reflector RPRSG (E-mail)
- Subject: Re: RPR perf: My thoughts
Khaled and Harry,
Are we assuming self-similar data traffic for the simulations or some
version of Poisson based traffic. Most internet traffic is TCP based
which has been proven to be self-similar.
The problem with simulating self-similar traffic (since it has
infinite variance) is that the simulations do not converge.
There are solutions via some analytical methods, but then the
performance would be done mostly analytically.
Regards,
Shahid Akhtar
Cyras Systems
----- Original Message -----
From: Harry Peng
To: khaledamer@xxxxxxx
Cc: Changcheng
Huang (E-mail) ; Reflector
RPRSG (E-mail)
Sent: Thursday, January 25, 2001 2:12 PM
Subject: RPR perf: My thoughts
Khaled:
<<Performance Ad Hoc Proposal.ppt>>
At last......As promised from last week's meeting.
Attached is some charts that capture to what we discussed over
lunch.
As you can see it addresses Raj's request for cut-through versus
store and forward.
You are welcome to modified the chart.
I'm basically requesting a need for a common test harness.
We need sponsors for the harness modules.
I've also tried to summarize the different RPR MAC proposals.
We can seek each proposal's supporter to do the simulation for each proposal.
Follow your guideline on traffic profile and metric we shall have a good platform for comparing the
different proposals.
I don't see how we can compare the results if we do not set a common simulation framework
for each RPR node.
Comments.....
Regards,
Harry
*****************************************************************************
P. Taylor Salman OPNET Technologies, Inc.
Manager, Market Research 3400 International Dr., NW
Phone: 202-364-4700x2297 Washington, DC 20008
Cell: 202-427-3319 tsalman@xxxxxxxxx
******************************************************************************