[Tmrg] Tmrg-interest Digest, Vol 19, Issue 6

Sat Apr 19 12:40:48 PDT 2008

Dear Lachlan,

could you please specify what you mean by "application data unit"?

I understand that tranfer time per flow is the time elapsed between the
arrival of the first bit at the destination and the arrival of the last
bit at the destination of a flow (during its lifetime)

why you consider option 2 meaningless?

Thanks for the clarification and sorry if I am out of phase (you asked for
interaction)

nelson fonseca

> Send Tmrg-interest mailing list submissions to
> 	tmrg-interest at ICSI.Berkeley.EDU
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
> or, via email, send a message with subject or body 'help' to
> 	tmrg-interest-request at ICSI.Berkeley.EDU
>
> You can reach the person managing the list at
> 	tmrg-interest-owner at ICSI.Berkeley.EDU
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tmrg-interest digest..."
>
>
> Today's Topics:
>
>    1. Test suite: Transfer time vs file size (Lachlan Andrew)
>    2. Re: Test suite: Transfer time vs file size (Hamed Haddadi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 18 Apr 2008 19:39:32 -0700
> From: "Lachlan Andrew" <lachlan.andrew at gmail.com>
> Subject: [Tmrg] Test suite: Transfer time vs file size
> To: tmrg <tmrg-interest at ICSI.Berkeley.EDU>
> Message-ID:
> 	<aa7d2c6d0804181939x64f7f4fawbc5aed5bc62f0ee5 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Greetings all,
>
> For the general scenarios, we specify one metric as the "transfer time
> per flow versus file size".
> How should we define that, given that the flows are mostly non-greedy?
>  Options include:
>
> 1. Treat each "application data unit" as a single flow.  That would
> mean the Tmix would have to record the statistics for us
> 2. Treach each entire connection as a single flow.  That would seem to
> give meaningless values.
> 3. Add some artificial greedy flows and only record statistics from them.
>
> My favourite option is 1.  What do others think?
>
>
> BTW, I know that lots of people read this list, but very few seem to
> post.  It would be great to have more interaction.  In particular,
> this test suite will only be successful if it represents a community
> consensus, and hence if people are willing to use it.
>
> Cheers,
> Lachlan
>
> --
> 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
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 19 Apr 2008 13:34:36 +0930
> From: "Hamed Haddadi" <hamed at ee.ucl.ac.uk>
> Subject: Re: [Tmrg] Test suite: Transfer time vs file size
> To: "Lachlan Andrew" <lachlan.andrew at gmail.com>
> Cc: tmrg <tmrg-interest at ICSI.Berkeley.EDU>
> Message-ID:
> 	<9d1bec780804182104o5c52576alc321282d195dd7ef at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Greetings all,
> I am not on TMRG but I folow these emailas they are really interesting,
>
> thought I just mention the fact that one tricky issue is the actual
> definition of flows in this context, weather a 2-day emule download or
> bittorrent session is one flow with constant up-down times, or
> numerous bursty individual flows, as opposed to a radio streaming that
> is active for days with constant bit rate, and also, is a gmail/msn
> chat etc flow which is active for many days without much activity is
> just considered one long flow with not much data on it.
>
> Internet is moving away from traditional heavy-tailed/self-similar
> nature and classic flow definition and sampling methods may not be
> representetive for future
>
> cheers
> hamed
>
> 2008/4/19 Lachlan Andrew <lachlan.andrew at gmail.com>:
>> Greetings all,
>>
>>  For the general scenarios, we specify one metric as the "transfer time
>>  per flow versus file size".
>>  How should we define that, given that the flows are mostly non-greedy?
>>   Options include:
>>
>>  1. Treat each "application data unit" as a single flow.  That would
>>  mean the Tmix would have to record the statistics for us
>>  2. Treach each entire connection as a single flow.  That would seem to
>>  give meaningless values.
>>  3. Add some artificial greedy flows and only record statistics from
>> them.
>>
>>  My favourite option is 1.  What do others think?
>>
>>
>>  BTW, I know that lots of people read this list, but very few seem to
>>  post.  It would be great to have more interaction.  In particular,
>>  this test suite will only be successful if it represents a community
>>  consensus, and hence if people are willing to use it.
>>
>>  Cheers,
>>  Lachlan
>>
>>  --
>>  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
>>
>>  --
>>  This message has been scanned for viruses and
>>  dangerous content by MailScanner, and is
>>  believed to be clean.
>>
>>
>
>
>
> --
> =================================================
> hamed at ee.ucl.ac.uk , http://www.ee.ucl.ac.uk/~hamed
> Currently at School of Mathematical Sciences, University of Adelaide
>
>
> ------------------------------
>
> _______________________________________________
> Tmrg-interest mailing list
> Tmrg-interest at ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
>
>
> End of Tmrg-interest Digest, Vol 19, Issue 6
> ********************************************
>