Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: RPR perf: My thoughts

Dear all,
 
    There are really two purposes to the RPR Perf. simulations.
 
1) Evaluate different proposals (and secondarily how it meets underlying performance objectives (QoS, SLA, TDM-encapsulation,
L2 Tunneled legacy protocols, etc).
 
2) Fine-tune the chosen RPR MAC direction to optimize the protocol.
 
    Since we are in #1 phase, we ought to focus on normalizing the
simulation environment and traffic types we will use to evaluate each
of the MAC proposals.  So I am agreeing w/ the Perf Ad Hoc group's
recommendation at the RPR Jan/01 interim.  I cannot think of any fairer method than asking each of the advocate to do the perf. simulation on the pre-agreed simulation environment and traffic cases.  The overall RPR group probably does not have the resources to coordinate all the permutations of [ MAC | CoS | Congestion | L3 protocol ]. 
 
    Let's focus.  Ad hoc should do what it said it would do.  Focus on standard [initial] set of simulation environment, so that each proposer could report on the results at the next meeting (or this reflector).  We could improve over time.
 
    regards,
 
Yong.

============================================
Yongbum "Yong" Kim      Direct (408)922-7502
Technical Director      Main   (408)501-7800
3151 Zanker Road        Fax    (408)434-6031
San Jose, CA 95134      Mobile (408)887-1058
http://www.broadcom.com   ybkim@xxxxxxxxxxxx
============================================
 

-----Original Message-----
From: owner-stds-802-rprsg@xxxxxxxx [mailto:owner-stds-802-rprsg@xxxxxxxx]On Behalf Of Taylor Salman
Sent: Saturday, January 27, 2001 9:16 AM
To: Sanjay Agrawal; 'Shahid Akhtar'; Harry Peng; khaledamer@xxxxxxx
Cc: Changcheng Huang (E-mail); Reflector RPRSG (E-mail); Charles Barry; Seshadri Srinivasan; Rajesh Desai; Samuel Li
Subject: 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
Fax:      202-364-8551                          www.opnet.com
Cell:      202-427-3319                          tsalman@xxxxxxxxx
******************************************************************************