[Tmrg] Fwd: Round-table PFLDnet submission

[Cesar Marcondes]

Dear Lachlan,

On Dec 2, 2007 11:49 PM, Lachlan Andrew <lachlan.andrew at gmail.com> wrote:
> Greetings all,
>
> Does silence mean people are happy with my new proposal to measure
> load in terms of simultaneous sessions in a processor sharing M/G/1
> queue?

Sorry, I'm a bit busy these days. I will try to comment on your load
proposal a bit.

1) "The load is varied by scaling the interarrival times by a
constant. We invite other researchers to test the assumption that the
file-size distribution is independent of the load". It sounds
reasonable to me, files exist in hard-drives, imho they shouldn't be
dependent on the load unless the dynamic content size is dependent on
the load.

2) Is there a straightforward algorithm to obtain the mean queue size
of M/G/1 using shortest-remaining-processing-time-first?
my concern here is more practical, is it necessary to code in ns-2 a
M/G/1 queue size solver for the test suite?
How about deriving loads based on standard reno? we set a fixed N
independent non-infinite TCP streams and measure the load based on
standard Reno. And this search of N process would find when the load
is ~10% and so on.

> We're aiming to have this settled within a week, so now would be a
> good time to comment on this or any other issues with the document
> (see attached .dvi).
>
> Also, I'd ask all authors to commit regularly to CVS so that we can
> all see the latest.

ok.

> Currently it looks like the RTT section is entirely empty.  Sally, do
> you mind if I cut-and-paste the discussion of RTTs from your section
> into that section?  Again, I'll take silence as permission :)  (We can
> always back it out of CVS.)

I run the scripts from http://www.icir.org/models/sims.html.
In the case of figure 4, the site says ...

## Figure 4, web traffic and long-lived flows, with a range of RTTs:
./ns sims.tcl -flows 18 -web 400 -rtts 1 -title two > two.data
csh sims.cmd; cp reda.eps sims2.eps; gv sims2.eps &

the log with the access links RTTs w/ 18 access links is attached.


>
> Cheers,
> Lachlan
>
>
> On 28/11/2007, Lachlan Andrew <lachlan.andrew at gmail.com> wrote:
> > Greetings Sally and everyone,
> >
> > In the description of delay/throughput tradeoff, it talks about
> > "moderate congestion" as 1-2% packet loss with NewReno.  Unless I'm
> > mistaken, that says "windows should be about 1/sqrt(0.01)=10 packets"
> > (to within a small factor).  I'd prefer not to quantify the load that
> > way.  Consider some scenarios:
> >
> > 56kbit/s:  10 packets of 12000 bits  > 200ms.  That means that for 56k
> > tests with inter-city RTTs (50ms), a moderate level of load would be
> > *half* of one flow.
> >
> > 100Mbit/s bottleneck, 100ms path.  "Moderate" congestion would be when
> > 2000 flows each gets about 50kbit/s.  To me, that is very heavy load.
> > Indeed, however large the bottleneck bandwidth is, "moderate"
> > congestion would be when 100ms paths give 50kbit/s per user.
> >
> >
> > I'd much prefer to specify the load in terms of the offered load as a
> > fraction of bandwidth.
> >
> > I propose an alternative:  The "load" is the average number of flows
> > if the traffic was served by an  M/G/1 queue with an ideal
> > processor-sharing service discipline.
> >
> > My reasons are:
> > 1. This scales properly as capacity increases, and is correctly
> > independent of RTT
> >
> > 2. A processor-sharing M/G/1 queue is a model of roughly what we're
> > aiming for with a single bottleneck (equal instantaneous rates).
> >
> > 3. For loads like 10%, this simply corresponds to 10% of the bandwidth.
> >
> > 4.  It reflects that, even at extreme overload, we want to consider a
> > system whose average number of flows doesn't increase with time.
> > Otherwise, the results would be   very   sensitive to duration, and we
> > agreed that we should try to design tests which are   not   sensitive
> > to the parameters.
> >
> > Thoughts?
>
>
> --
>
> Lachlan Andrew  Dept of Computer Science, Caltech
> 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
> Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
> http://netlab.caltech.edu/~lachlan
>

> _______________________________________________
> Tmrg-interest mailing list
> Tmrg-interest at ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rtts_bettermodels_fig4.txt
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/tmrg-interest/attachments/20071204/6fb20be4/attachment.txt