|
I
agree with Sanjay, In addition to traces, we also need to run TCP
although the RPR MAC doesn't include L4 protocol. Based on our
simulation
results, we have observed that TCP flows sometimes
do synchronize and become bursty on the ring (as also happen in switches
and routers),
presenting quite a challenge to the design of flow
control algorithms.
So
it's important to make sure that an RPR flow control doesn't collapse under TCP
or other similar adaptive traffic. We might want to verify
key
parameters such as fairness, ring utilization,
ring transit delay in a presence of TCP traffic.
Adisak
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
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 -----
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
|