Re: RPR perf: My thoughts
Hi All,
TCP traffic performance over RPR is definitely the most important part of
RPR MAC evaluation. However, I don't think TCP traffic performance over RPR
should be the first step. What we need here is to establish a clean and
simplistic RPR MAC performance baseline in a timely manner. TCP network
behavior can be pathological due to many reasons ranging from application,
RTT estimation factors to TCP simulation models. By just specifying a Tahoe
or any other flavor of TCP would not bring consensus to TCP traffic
generation specification any time sooner.
Using raw UDP traffic will never produce a definitive performance
conclusion for RRP MAC, but it does allow us to focus on RPR MAC
performance baseline. RPR MAC performance evaluation should be a
progressive advancing process, from simple to complex and from partial to
complete. Any shortcut may well be counter productive and time consuming.
I support raw UDP traffic as step #1 simulation.
Best Regards,
Donghui Xie
At 10:22 AM 1/30/01 -0800, Khaled Amer wrote:
>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