From lachlan.andrew at gmail.com Tue Apr 1 19:35:09 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Tue, 1 Apr 2008 19:35:09 -0700 Subject: [Tmrg] Towards a Common TCP Evaluation Suite In-Reply-To: <15CDB731-42C9-430A-832A-B21A1824AE40@mac.com> References: <5D977804-59A9-4A06-8E71-4C88AF56FA50@csnet.cs.odu.edu> <56D7B140-63DE-4560-91E6-46C70F7A4583@mac.com> <19B51173-135B-4D82-BF98-086118F2599E@mac.com> <15CDB731-42C9-430A-832A-B21A1824AE40@mac.com> Message-ID: Greetings all, Let's get back onto the test suite... I propose the following text for the multi-hop test: The topology is a ``parking-lot'' topology with three (horizontal) bottleneck links and four (vertical) access links. The bottleneck links have a rate of 100\,Mbps, and the access links have a rate of 1\,Gbps. All flows have a round-trip time of 60\,ms. This can be achieved by all links having a one-way delay of 10\,ms. Alternatively, it may be achieved by (a) the second access link having a one-way delay of 30\,ms (b) the bottleneck link to which it does not connect having a one-way delay of 30\,ms and (c) all other links having negligible delay. (The latter configuration can be extended to more than three bottlenecks, by assigning a delay of 30\,ms to every alternate access link, and to zero or one of the bottleneck links.) Other points: - For the "satellite" link, why does the central (satellite) link have a symmetric bit rate, while the ground links are asymmetric? I'd suggest making the central link 40M/4M, and the ground links all symmetric, either at 40M or preferably at 100M or 1G. - The "dial-up" case uses 64kbit/s. Should we perhaps make that 56kbit/s in one direction and 48kbit/s in the other, which is the best available from a V.92 modem? - What format should we use for the Internet draft -- xml? nroff? I'm hoping to patch tmix to let it re-use the same input file for multiple different traffic loads, but that will take a bit of time... Cheers, Lachlan On 18/03/2008, Sally Floyd wrote: > > On Mar 18, 2008, at 10:12 AM, Lachlan Andrew wrote: > > > Greetings Sally, > > > > On 18/03/2008, Sally Floyd wrote: > >> > >> I think it makes more sense to specify the topology as it is > >> specified > >> now in Section G ("a "parking-lot" topology with three (horizontal) > >> bottleneck > >> links and four (vertical) access links"), and then to add that in a > >> testbed, this can be *implemented* with only N delay elements. > > > > I wasn't proposing a change to the arrangements of links, just the > > allocation of delays on those links. The description above describes > > both delay allocations equally well. The only distinction is whether > > all links have equal delay, or two have large delays and the rest have > > negligible delays. > > > > If the two delay arrangements are equivalent (as I believe they are) > > then I agree it is good to describe the symmetric one and note that > > the asymmetric one is equivalent. It would only become awkward if > > there is a useful metric for which they give different results. > > > My assumption was this topology: > > A ------ B ------ C ------ D > > with four access links, A-E, B-F, C-G, D-H. > (I didn't draw the access links, because I don't trust mail > readers to all present it the same way...) > > The flows with multiple bottlenecks go from A to D, and vice versa. > The single bottleneck flows go between E and F, F and G, and G and > H. So there are three congested links, and four separate paths. > All paths have the same 60 ms round-trip time (in the absence of > queueing delay.) > > So I am assuming that you want the links B-F and C-D to each have a > 30 ms. one-way delay, and for the other links to have 0 ms. delay. > Or something like that. But for all links to have the same > queue sizes and such. > > I would be happy for the paper to describe the symmetric case, > and to note that the asymmetric case is roughly equivalent. > (I wouldn't expect it to be *exactly* equivalent, because the > timing of packets arriving at forward-path and reverse-path > queues should be slightly different.) > > > - Sally > http://www.icir.org/floyd/ > > -- 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 From ldunn at cisco.com Wed Apr 2 11:07:38 2008 From: ldunn at cisco.com (Lawrence D. Dunn) Date: Wed, 2 Apr 2008 13:07:38 -0500 Subject: [Tmrg] Towards a Common TCP Evaluation Suite In-Reply-To: References: <5D977804-59A9-4A06-8E71-4C88AF56FA50@csnet.cs.odu.edu> <56D7B140-63DE-4560-91E6-46C70F7A4583@mac.com> <19B51173-135B-4D82-BF98-086118F2599E@mac.com> <15CDB731-42C9-430A-832A-B21A1824AE40@mac.com> Message-ID: Lachlan, At the Stanford Trainwreck workshop yesterday (missed you!), http://yuba.stanford.edu/trainwreck/agenda.html there was someone from NIST who indicated they were working on a for-the-good-of-the-community TCP test suite, or similar. There was brief discussion on whether NIST would come up with some sort of "compliance testing" (generally viewed as "bad" by the crowd), or some sort of standard comparison tests. Which sounds a lot like what we're doing, which I mentioned to the group... Anyway, would you be game to ping the NIST person, and see how much commonality/overlap there is, whether there'd be synergy in some collaboration, etc? The only NIST person on the attendee list is: Vladimir Marbukh, NIST, malones at nist.gov (note the email addr doesn't seem to match the person-name; maybe it's OK, or maybe it's an admin, not sure...) Thoughts from others on this list? I hadn't heard about the NIST work before, and one might argue that too close an interaction w/ NIST might compromise the not-nation-specific nature of our work, etc. Still, to reduce duplication and try for a more broadly applicable outcome, might be worth seeing what they're up to... Larry -- At 7:35 PM -0700 4/1/08, Lachlan Andrew wrote: >Greetings all, > >Let's get back onto the test suite... > >I propose the following text for the multi-hop test: > > The topology is a ``parking-lot'' topology with > three (horizontal) bottleneck links and four (vertical) access links. > The bottleneck links have a rate of 100\,Mbps, > and the access links have a rate of 1\,Gbps. > > All flows have a round-trip time of 60\,ms. > This can be achieved by all links having a one-way delay of 10\,ms. > Alternatively, it may be achieved by (a) the second access link >having a one-way > delay of 30\,ms (b) the bottleneck link to which it does not >connect having a > one-way delay of 30\,ms and (c) all other links having negligible delay. > (The latter configuration can be extended to more than three bottlenecks, by > assigning a delay of 30\,ms to every alternate access link, and to >zero or one > of the bottleneck links.) > >Other points: >- For the "satellite" link, why does the central (satellite) link have >a symmetric bit rate, while the ground links are asymmetric? I'd >suggest making the central link 40M/4M, and the ground links all >symmetric, either at 40M or preferably at 100M or 1G. > >- The "dial-up" case uses 64kbit/s. Should we perhaps make that >56kbit/s in one direction and 48kbit/s in the other, which is the >best available from a V.92 modem? > >- What format should we use for the Internet draft -- xml? nroff? > >I'm hoping to patch tmix to let it re-use the same input file for >multiple different traffic loads, but that will take a bit of time... > >Cheers, >Lachlan > >On 18/03/2008, Sally Floyd wrote: >> >> On Mar 18, 2008, at 10:12 AM, Lachlan Andrew wrote: >> >> > Greetings Sally, >> > >> > On 18/03/2008, Sally Floyd wrote: >> >> >> >> I think it makes more sense to specify the topology as it is >> >> specified >> >> now in Section G ("a "parking-lot" topology with three (horizontal) >> >> bottleneck >> >> links and four (vertical) access links"), and then to add that in a >> >> testbed, this can be *implemented* with only N delay elements. >> > >> > I wasn't proposing a change to the arrangements of links, just the >> > allocation of delays on those links. The description above describes >> > both delay allocations equally well. The only distinction is whether >> > all links have equal delay, or two have large delays and the rest have >> > negligible delays. >> > >> > If the two delay arrangements are equivalent (as I believe they are) >> > then I agree it is good to describe the symmetric one and note that >> > the asymmetric one is equivalent. It would only become awkward if > > > there is a useful metric for which they give different results. >> >> >> My assumption was this topology: >> >> A ------ B ------ C ------ D >> >> with four access links, A-E, B-F, C-G, D-H. >> (I didn't draw the access links, because I don't trust mail >> readers to all present it the same way...) >> >> The flows with multiple bottlenecks go from A to D, and vice versa. >> The single bottleneck flows go between E and F, F and G, and G and >> H. So there are three congested links, and four separate paths. >> All paths have the same 60 ms round-trip time (in the absence of >> queueing delay.) >> >> So I am assuming that you want the links B-F and C-D to each have a >> 30 ms. one-way delay, and for the other links to have 0 ms. delay. >> Or something like that. But for all links to have the same >> queue sizes and such. >> >> I would be happy for the paper to describe the symmetric case, >> and to note that the asymmetric case is roughly equivalent. >> (I wouldn't expect it to be *exactly* equivalent, because the >> timing of packets arriving at forward-path and reverse-path >> queues should be slightly different.) >> >> >> - Sally >> http://www.icir.org/floyd/ >> >> > > >-- >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 From lachlan.andrew at gmail.com Wed Apr 2 14:23:31 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 2 Apr 2008 13:23:31 -0800 Subject: [Tmrg] Towards a Common TCP Evaluation Suite In-Reply-To: References: <5D977804-59A9-4A06-8E71-4C88AF56FA50@csnet.cs.odu.edu> <56D7B140-63DE-4560-91E6-46C70F7A4583@mac.com> <19B51173-135B-4D82-BF98-086118F2599E@mac.com> <15CDB731-42C9-430A-832A-B21A1824AE40@mac.com> Message-ID: Thanks Larry. I would have like to go, but didn't get my act together... Thanks for the pointer. It would certainly be good to cooperate. Cheers, Lachlan On 02/04/2008, Lawrence D. Dunn wrote: > Lachlan, > At the Stanford Trainwreck workshop yesterday (missed you!), > http://yuba.stanford.edu/trainwreck/agenda.html > > there was someone from NIST who indicated they were working > on a for-the-good-of-the-community TCP test suite, or similar. > There was brief discussion on whether NIST would come up > with some sort of "compliance testing" (generally viewed as "bad" > by the crowd), > or some sort of standard comparison tests. > Which sounds a lot like what we're doing, which I mentioned to the > group... > > Anyway, would you be game to ping the NIST person, > and see how much commonality/overlap there is, > whether there'd be synergy in some collaboration, etc? > > The only NIST person on the attendee list is: > Vladimir Marbukh, NIST, malones at nist.gov > (note the email addr doesn't seem to match the person-name; > maybe it's OK, or maybe it's an admin, not sure...) > > Thoughts from others on this list? I hadn't heard about the NIST > work before, and one might argue that too close an interaction > w/ NIST might compromise the not-nation-specific nature of > our work, etc. Still, to reduce duplication and try for a > more broadly applicable outcome, might be worth seeing what > they're up to... > > Larry > -- > > > At 7:35 PM -0700 4/1/08, Lachlan Andrew wrote: > > > > > Greetings all, > > > > Let's get back onto the test suite... > > > > I propose the following text for the multi-hop test: > > > > The topology is a ``parking-lot'' topology with > > three (horizontal) bottleneck links and four (vertical) access links. > > The bottleneck links have a rate of 100\,Mbps, > > and the access links have a rate of 1\,Gbps. > > > > All flows have a round-trip time of 60\,ms. > > This can be achieved by all links having a one-way delay of 10\,ms. > > Alternatively, it may be achieved by (a) the second access link > > having a one-way > > delay of 30\,ms (b) the bottleneck link to which it does not connect > having a > > one-way delay of 30\,ms and (c) all other links having negligible delay. > > (The latter configuration can be extended to more than three bottlenecks, > by > > assigning a delay of 30\,ms to every alternate access link, and to zero > or one > > of the bottleneck links.) > > > > Other points: > > - For the "satellite" link, why does the central (satellite) link have > > a symmetric bit rate, while the ground links are asymmetric? I'd > > suggest making the central link 40M/4M, and the ground links all > > symmetric, either at 40M or preferably at 100M or 1G. > > > > - The "dial-up" case uses 64kbit/s. Should we perhaps make that > > 56kbit/s in one direction and 48kbit/s in the other, which is the > > best available from a V.92 modem? > > > > - What format should we use for the Internet draft -- xml? nroff? > > > > I'm hoping to patch tmix to let it re-use the same input file for > > multiple different traffic loads, but that will take a bit of time... > > > > Cheers, > > Lachlan > > > > On 18/03/2008, Sally Floyd wrote: > > > > > > > > On Mar 18, 2008, at 10:12 AM, Lachlan Andrew wrote: > > > > > > > Greetings Sally, > > > > > > > > On 18/03/2008, Sally Floyd wrote: > > > >> > > > >> I think it makes more sense to specify the topology as it is > > > >> specified > > > >> now in Section G ("a "parking-lot" topology with three (horizontal) > > > >> bottleneck > > > >> links and four (vertical) access links"), and then to add that in a > > > >> testbed, this can be *implemented* with only N delay elements. > > > > > > > > I wasn't proposing a change to the arrangements of links, just the > > > > allocation of delays on those links. The description above describes > > > > both delay allocations equally well. The only distinction is whether > > > > all links have equal delay, or two have large delays and the rest > have > > > > negligible delays. > > > > > > > > If the two delay arrangements are equivalent (as I believe they are) > > > > then I agree it is good to describe the symmetric one and note that > > > > the asymmetric one is equivalent. It would only become awkward if > > > > > > > there is a useful metric for which they give different results. > > > > > > > > > > > My assumption was this topology: > > > > > > A ------ B ------ C ------ D > > > > > > with four access links, A-E, B-F, C-G, D-H. > > > (I didn't draw the access links, because I don't trust mail > > > readers to all present it the same way...) > > > > > > The flows with multiple bottlenecks go from A to D, and vice versa. > > > The single bottleneck flows go between E and F, F and G, and G and > > > H. So there are three congested links, and four separate paths. > > > All paths have the same 60 ms round-trip time (in the absence of > > > queueing delay.) > > > > > > So I am assuming that you want the links B-F and C-D to each have a > > > 30 ms. one-way delay, and for the other links to have 0 ms. delay. > > > Or something like that. But for all links to have the same > > > queue sizes and such. > > > > > > I would be happy for the paper to describe the symmetric case, > > > and to note that the asymmetric case is roughly equivalent. > > > (I wouldn't expect it to be *exactly* equivalent, because the > > > timing of packets arriving at forward-path and reverse-path > > > queues should be slightly different.) > > > > > > > > > - Sally > > > http://www.icir.org/floyd/ > > > > > > > > > > > > > > > -- > > 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 > > > > -- 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 From garmitage at swin.edu.au Wed Apr 2 15:03:03 2008 From: garmitage at swin.edu.au (grenville armitage) Date: Thu, 03 Apr 2008 09:03:03 +1100 Subject: [Tmrg] Towards a Common TCP Evaluation Suite In-Reply-To: References: <5D977804-59A9-4A06-8E71-4C88AF56FA50@csnet.cs.odu.edu> <56D7B140-63DE-4560-91E6-46C70F7A4583@mac.com> <19B51173-135B-4D82-BF98-086118F2599E@mac.com> <15CDB731-42C9-430A-832A-B21A1824AE40@mac.com> Message-ID: <47F40297.3030503@swin.edu.au> Hi Lachlan, Lachlan Andrew wrote: [..] > - The "dial-up" case uses 64kbit/s. Should we perhaps make that > 56kbit/s in one direction and 48kbit/s in the other, which is the > best available from a V.92 modem? I'd prefer to see ~52kbit/sec down and 33kbit/sec up for the "dial-up" case, to model the (IMHO more likely) V.90 case rather than V.92. (Also I note a comment on http://en.wikipedia.org/wiki/V.92#V.92 that V.92's upstream 48kbit/sec only occurs if you're willing take a hit on the downstream rate... although, I'm taking the easy way out here by relying on a wikipedia article. Perhaps someone else can clarify the relevance / market penetration of V.92 today?) cheers, gja From lachlan.andrew at gmail.com Sun Apr 6 10:48:17 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Sun, 6 Apr 2008 10:48:17 -0700 Subject: [Tmrg] TCP Evaluation Suite: Traffic Generator In-Reply-To: References: <200804040901.05989.ralfluebben@gmx.de> Message-ID: Greetings Ralf, On 04/04/2008, Ralf L?bben wrote: > > I really like the idea of the TCP Evaluation Suite because the standardized > testing and the predefined scenarios. > > I read in the paper from PFLDnet2008, that you still search researchers for > the traffic generator. > > As I understand at the moment you will use Tmix, which replays application > workload based on packet traces independent from several applications. > > What is there still a need for? > > A distribution for this application independent workload? > > or > > A detail analysis of the influence of the user behavior (e.g., think times > etc.) These are traffic measurement issues, rather than traffic generator issues. We need both of those, and also models for the influence *on* user behaviour -- that is, how congestion affects user behaviour rather than vice versa. Do users give up and leave, or do they abort connections and retry, or do they just sit patiently and leave their load unchanged? Do think times increase, because users go away and do something else, or decrease because the user has already read the text of a page by the time the images have finished loading? Related questions are: - How do traffic parameters change during congestion? Normally the inter-flow times will be reduced, but are the file sizes higher or lower, and more or less heavy tailed? - How does mean file size vary with link capacity? For example, people wanting to transfer very large files won't do so on a very low-speed link. As far as traffic generators themselves go, we'll probably stick with Tmix and enhance it to meet our needs. For example, we want to be able to specify the MSS of a flow, which I don't think it can currently do. We also want one sender to be able to send to multiple receivers. Do you mind if I forward this mail to the TMRG mailing list? 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 From lachlan.andrew at gmail.com Wed Apr 9 20:03:21 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 9 Apr 2008 20:03:21 -0700 Subject: [Tmrg] Traffic trace options Message-ID: Greetings all, A few people have asked for the traffic traces for the test suite. How does this suggestion sound: UNC have provided us with two traces. Both are bidirectional, specify the RTT of each flow, and are about one hour. One is for sessions started by a host inside their campus and one for sessions started outside. For simplicity, I propose using only the larger of these two. I've been told that Tmix can scale traffic loads, so that should do for all load cases. We need 9 separate traces for the 9 source/destination pairs, plus another 9 in the reverse direction. I propose subsampling the trace to do that. (That should maintain the correct correlation structure, while overlaying 9 time-delayed copies of the same trace would reduce burstiness.) To do the subsampling, I propose sorting the sessions by RTT, and allocating the top 11% to the S/D pair with the longest RTT etc. I also propose using a cyclic permutation of the trace, so that the first 100s or so has the same load as the average over the entire trace, to try to minimise the bias introduced by running very short experiments. Feedback on these proposals would be most welcome (or ask me to explain it more clearly). If no-one has any objections or suggestions, Tom Q will post the 9 resulting traces on the web sometime next week. 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 From sallyfloyd at mac.com Wed Apr 16 15:05:17 2008 From: sallyfloyd at mac.com (Sally Floyd) Date: Wed, 16 Apr 2008 15:05:17 -0700 Subject: [Tmrg] Towards a Common TCP Evaluation Suite - traffic generator question In-Reply-To: References: <02cf01c88d7d$d82c4ef0$c44c1cac@ad.research.nec.com.cn> Message-ID: Lachlan - (Sorry, this is Sally finally getting to old March 24 email...) > The Full-TCP issue also applies to the main set of "general tests". > One one hand, I think that the authors of a modification to TCP should > be willing to write it for the Full-TCP module. On the other hand, > this is another reason to go back to Harpoon, especially if people > want to compare their enhancements to the existing enhancements. For the tests using the ns-2 simulator, I think that tests that were limited to use with the Full-TCP module wouldn't be very useful to the general research community. Just FYI. (1) Full-TCP has never been validated as fully as the one-way TCP in ns-2. The following very old note on the ns-2 web page at "http://www.isi.edu/nsnam/ns/ns-limitations.html" is largely still valid: "Limitations to FullTCP: There is not a complete validation test suite for FullTCP." If anyone ever wanted to extend the validation tests in ns-2 for FullTCP, that would be great. (2) I would note that I am not funded as a support person for ns-2 - I work on ns-2 because I use it in my own research. I add validation tests to ns-2 for one-way TCP because I use one-way TCP in my own research. I add functionality to one-way TCP generally because that is what I have needed for my own research. There is a very great deal of functionality, from me and from many other researchers, that is available on one-way TCP but not on Full-TCP in ns-2. There is a very limited functionality that is available on Full-TCP. - Sally http://www.icir.org/floyd/ From lachlan.andrew at gmail.com Wed Apr 16 16:20:22 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 16 Apr 2008 16:20:22 -0700 Subject: [Tmrg] Towards a Common TCP Evaluation Suite - traffic generator question In-Reply-To: References: <02cf01c88d7d$d82c4ef0$c44c1cac@ad.research.nec.com.cn>

Message-ID: Thanks Sally. Limited testing of Full-TCP is a good point. Michele has said that they are already working on extending Tmix, so the issue should soon be solved. Cheers, Lachlan On 16/04/2008, Sally Floyd wrote: > Lachlan - > > (Sorry, this is Sally finally getting to old March 24 email...) > > > > The Full-TCP issue also applies to the main set of "general tests". > > One one hand, I think that the authors of a modification to TCP should > > be willing to write it for the Full-TCP module. On the other hand, > > this is another reason to go back to Harpoon, especially if people > > want to compare their enhancements to the existing enhancements. > > > > > For the tests using the ns-2 simulator, I think that tests that were > limited to use with the Full-TCP module wouldn't be very useful > to the general research community. Just FYI. > > > (1) Full-TCP has never been validated as fully as the one-way > TCP in ns-2. The following very old note on the ns-2 web page > at "http://www.isi.edu/nsnam/ns/ns-limitations.html" is > largely > still valid: > > "Limitations to FullTCP: There is not a complete validation test suite > for FullTCP." > > If anyone ever wanted to extend the validation tests in ns-2 for > FullTCP, that would be great. > > > (2) I would note that I am not funded as a support person for ns-2 - > I work on ns-2 because I use it in my own research. I add validation > tests to ns-2 for one-way TCP because I use one-way TCP in my own > research. I add functionality to one-way TCP generally because > that is what I have needed for my own research. > > There is a very great deal of functionality, from me and from many > other researchers, that is available on one-way TCP but not on > Full-TCP in ns-2. There is a very limited functionality that is available > on Full-TCP. > > > - Sally > http://www.icir.org/floyd/ > > -- 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 From sallyfloyd at mac.com Wed Apr 16 18:16:18 2008 From: sallyfloyd at mac.com (Sally Floyd) Date: Wed, 16 Apr 2008 18:16:18 -0700 Subject: [Tmrg] Towards a Common TCP Evaluation Suite - traffic generator question In-Reply-To: References: <02cf01c88d7d$d82c4ef0$c44c1cac@ad.research.nec.com.cn>

Message-ID: <7AA549C7-E8B6-440D-A1DB-CC70EBCD499A@mac.com> Lachlan - > Thanks Sally. Limited testing of Full-TCP is a good point. > > Michele has said that they are already working on extending Tmix, so > the issue should soon be solved. Great, thanks! - Sally http://www.icir.org/floyd/ From lachlan.andrew at gmail.com Fri Apr 18 19:39:32 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 18 Apr 2008 19:39:32 -0700 Subject: [Tmrg] Test suite: Transfer time vs file size Message-ID: 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 From hamed at ee.ucl.ac.uk Fri Apr 18 21:04:36 2008 From: hamed at ee.ucl.ac.uk (Hamed Haddadi) Date: Sat, 19 Apr 2008 13:34:36 +0930 Subject: [Tmrg] Test suite: Transfer time vs file size In-Reply-To: References: Message-ID: <9d1bec780804182104o5c52576alc321282d195dd7ef@mail.gmail.com> 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 : > 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 From nfonseca at ic.unicamp.br Sat Apr 19 12:40:48 2008 From: nfonseca at ic.unicamp.br (nfonseca at ic.unicamp.br) Date: Sat, 19 Apr 2008 16:40:48 -0300 (BRT) Subject: [Tmrg] Tmrg-interest Digest, Vol 19, Issue 6 In-Reply-To: References: Message-ID: <3833.143.106.7.122.1208634048.squirrel@webmail.ic.unicamp.br> 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" > Subject: [Tmrg] Test suite: Transfer time vs file size > To: tmrg > Message-ID: > > 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" > Subject: Re: [Tmrg] Test suite: Transfer time vs file size > To: "Lachlan Andrew" > Cc: tmrg > 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 : >> 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 > ******************************************** > From lachlan.andrew at gmail.com Sun Apr 20 22:09:50 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Sun, 20 Apr 2008 22:09:50 -0700 Subject: [Tmrg] Test suite: Transfer time vs file size Message-ID: Greetings, On 19/04/2008, nfonseca at ic.unicamp.br wrote: > > could you please specify what you mean by "application data unit"? I meant a burst of traffic whose rate is governed by TCP -- I think that is what the Tmix team mean by the term. A TCP connection consists essentially of a sequence of ADUs separated by idle times when the application has no data to send. > 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? It is meaningless for non-greedy flows, because the elapsed time is often dominated by times when the application has no data to send, rather than by TCP. This is like Hamed's example of a chat session. If a chat session is a single long-lived TCP connection, then we don't care that we only get a fraction of a bit per second, as long as each burst that we send gets sent quickly. Option 2 makes sense if the flow is *greedy*, so that TCP determines the total transfer time (that is, the flow consists of a single application data unit). In that case options 1 and 2 are identical. > Thanks for the clarification and sorry if I am out of phase (you asked for > interaction) Yes, thanks for the interaction. 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 From rchertov at purdue.edu Mon Apr 21 11:12:13 2008 From: rchertov at purdue.edu (Roman Chertov) Date: Mon, 21 Apr 2008 14:12:13 -0400 Subject: [Tmrg] router buffer sizes Message-ID: <480CD8FD.20509@purdue.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I am posting this email as per my conversation with Lachlan at INFOCOM. In our INFOCOM, "A Device Independent Router Model", paper and in our current work that extends that paper, we used empirical methods to ascertain the size of queues in various commercial routers. In the four commercial routers that we have experimented with, we have observed the following queue configurations: Byte Based Slot Based Separate buffers for various packet ranges (small, medium, large) Furthermore, the delay due to queuing ranged from 14 ms to almost 400 ms. In a variety of TCP papers that I have read, people used either default queue sizes in ns-2 (50 slots), or they used some arbitrary queue size. I think it will be useful for the future version of ns-3 to provide a variety of router "groups". Each group would be a collection of commercial routers which have similar characteristics, and then some representative for the group can be chosen. For instance, if an experimenter creates a routing node with many 1+ Gbps links, then choosing a queue size of 200 is not very representative of the real world. However, for such a scenario, choosing a group "backbone" will configure routing node to have fairly large queues of 16K+ packet slots, hence making the test more representative of a real network. The major problem with the proposed approach is the difficulty of obtaining the data. Sometimes the data is available on a company's website, in other cases, empirical methods are required to get the needed information. The major drawback of an empirical approach is the need for physical hardware. However, even with the drawbacks, I think it is worthwhile to do this, as then simulation accuracy should increase. Our INFOCOM paper is available at: http://www.cs.purdue.edu/homes/fahmy/papers/infocom08-roman.pdf Roman Chertov -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIDNj9T8ksiSCF2AYRAggkAJ9kErv4P61YvE3rmKbiJECIgtoLBwCdGLEL W2SGc2YqjPQg07OV9fNjrbA= =8mxv -----END PGP SIGNATURE----- From sallyfloyd at mac.com Mon Apr 28 08:24:13 2008 From: sallyfloyd at mac.com (Sally Floyd) Date: Mon, 28 Apr 2008 08:24:13 -0700 Subject: [Tmrg] Test suite: Transfer time vs file size In-Reply-To: References: Message-ID: Lachlan - On Apr 18, 2008, at 7:39 PM, Lachlan Andrew wrote: > 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? That makes sense to me. (Replying late...) - Sally http://www.icir.org/floyd/