From sallyfloyd at mac.com Mon Nov 5 15:35:07 2007 From: sallyfloyd at mac.com (Sally Floyd) Date: Mon, 5 Nov 2007 15:35:07 -0800 Subject: [Tmrg] flow completion times in uncongested systems In-Reply-To: References: Message-ID: <931ed46c0e4ce65fa8d7611e23060393@mac.com> > - The rise time of a single flow to an empty systems is not very > interesting, because it many measures the impact of slow start. Actually, the flow completion time in an uncongested system can be a quite interesting thing to measure, particularly if one is evaluating one of the many proposals for start-ups faster than slow-start. (One of these proposals is Quick-Start, RFC 4782; some of the others are discussed in Appendix A of RFC 4782.) I would recommend having scenarios include the case of a generally-uncongested link, as well as including cases with various levels of congestion, with metrics including per-flow transfer times, fairness, and aggregate packet drop rates. This should illustrate some of the good and potentially-bad aspects of protocols with fast start-ups. - Sally http://www.icir.org/floyd/ RFC 4782: http://www.ietf.org/rfc/rfc4782.txt From lachlan.andrew at gmail.com Mon Nov 5 15:42:54 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Mon, 5 Nov 2007 15:42:54 -0800 Subject: [Tmrg] TCP evaluation suite round-table In-Reply-To: References: Message-ID: Greetings all, Thanks to those who have agreed to attend the TCP evaluation round table. If anyone else would like to attend by EVO video conference, please let me know. There is still time to give feedback on the tentative schedule at I've also tentatively allocated a "discussion leader" to each session, as follows: Thursday: Lachlan Andrew Opening discussion of scope of this meeting Cesar Marcondes Benchmarking Scenario Parameters (Bandwidth, Delay, Buffer) Lars Eggert Measure of Utilization Bob Shorten Overall Responsiveness / Convergence Time Discussion Sally Floyd New algorithms Impact on Cross-Traffic Friday: Sangtae Ha Managing the Curse of Dimensionality on Core Tests Gang Wang Basic Core Scenarios Larry Dunn Basic Cross-Traffic Models Bob, will you be OK to lead the discussion by voice link, or do you think it would be better for someone present in person to do it? My current hope is that we can write up the agreement as a PFLDnet paper, with the discussion leaders writing the first draft of their respective sections. Ideally it would be good for this to progress into a TMRG draft, but I don't think we'll get there this 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 Mon Nov 5 15:50:23 2007 From: sallyfloyd at mac.com (Sally Floyd) Date: Mon, 5 Nov 2007 15:50:23 -0800 Subject: [Tmrg] [Iccrg] TCP evaluation suite round-table In-Reply-To: References: Message-ID: <3929de282a33daa94925ac99c258ce53@mac.com> Lachlan Many thanks for the "Literature Review" web pages attached to the agenda at "http://wil.cs.caltech.edu/mwiki/index.php?title=Round_table_agenda". Documents that could be added to the literature review include the following: * S. Floyd and E. Kohler, "Tools for the Evaluation of Simulation and Testbed Scenarios", internet-draft draft-irtf-tmrg-tools-04, work in progress, July 2007. - http://tools.ietf.org/html/draft-irtf-tmrg-tools-04 * S. Floyd and E. Kohler, "Internet Research Needs Better Models", Hotnets-I, October 2002. - http://www.icir.org/models/hotnetsFinal.pdf * "Internet Research Needs Better Models" web site, - http://www.icir.org/models/bettermodels.html (With web pages on topology modeling, traffic generation, and the like. * "Transport Modeling Research Group" web page, - http://www.icir.org/tmrg/ - Sally http://www.icir.org/floyd/ From lachlan.andrew at gmail.com Mon Nov 5 15:55:13 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Mon, 5 Nov 2007 15:55:13 -0800 Subject: [Tmrg] flow completion times in uncongested systems In-Reply-To: <931ed46c0e4ce65fa8d7611e23060393@mac.com> References: <931ed46c0e4ce65fa8d7611e23060393@mac.com> Message-ID: Greetings Sally, On 05/11/2007, Sally Floyd wrote: > > - The rise time of a single flow to an empty systems is not very > > interesting, because it many measures the impact of slow start. > > Actually, the flow completion time in an uncongested system can be > a quite interesting thing to measure, particularly if one is > evaluating one of the many proposals for start-ups faster than > slow-start. (One of these proposals is Quick-Start, RFC 4782; some > of the others are discussed in Appendix A of RFC 4782.) True. I should have said that this is a very different quantity from the responsiveness of the algorithm to control the window after slow start. As you say, it is of independent interest. > I would recommend having scenarios include the case of a > generally-uncongested link, as well as including cases with various > levels of congestion, with metrics including per-flow transfer > times, fairness, and aggregate packet drop rates. This should > illustrate some of the good and potentially-bad aspects of protocols > with fast start-ups. Yes, testing a range of levels of congestion is good. My concern was that we should not just measure the performance of a post-slow-start modification by observing slow-start behaviour. 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 Mon Nov 5 15:57:21 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Mon, 5 Nov 2007 15:57:21 -0800 Subject: [Tmrg] [Iccrg] TCP evaluation suite round-table In-Reply-To: <3929de282a33daa94925ac99c258ce53@mac.com> References: <3929de282a33daa94925ac99c258ce53@mac.com> Message-ID: Thanks for the links, Sally. Cesar Marcondes from UCLA actually did the literature reviews up, so all credit goes to him. Cheers, Lachlan On 05/11/2007, Sally Floyd wrote: > Lachlan > > Many thanks for the "Literature Review" web pages attached to the > agenda at > "http://wil.cs.caltech.edu/mwiki/index.php?title=Round_table_agenda". > > > Documents that could be added to the literature review include > the following: > > * S. Floyd and E. Kohler, "Tools for the Evaluation of Simulation > and Testbed Scenarios", internet-draft draft-irtf-tmrg-tools-04, > work in progress, July 2007. > - http://tools.ietf.org/html/draft-irtf-tmrg-tools-04 > > * S. Floyd and E. Kohler, "Internet Research Needs Better Models", > Hotnets-I, October 2002. > - http://www.icir.org/models/hotnetsFinal.pdf > > * "Internet Research Needs Better Models" web site, > - http://www.icir.org/models/bettermodels.html > (With web pages on topology modeling, traffic generation, and the > like. > > * "Transport Modeling Research Group" web page, > - http://www.icir.org/tmrg/ > > - Sally > http://www.icir.org/floyd/ > > _______________________________________________ > 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 sallyfloyd at mac.com Mon Nov 5 16:11:06 2007 From: sallyfloyd at mac.com (Sally Floyd) Date: Mon, 5 Nov 2007 16:11:06 -0800 Subject: [Tmrg] Round table: level of realism of tests? In-Reply-To: References: <46F98369.8030605@psc.edu> <65b35fd1d6c8959209fe942f1c5ddece@mac.com> Message-ID: Lachlan - My apologies for responding a month late on this! My unanswered email folder has been building up on me. ... > Motivated by past debates over different labs' tests, I was also more > interested in repeatability than realism. If we get different results > using simulation from dummynet or different results using dummynet > from real WAN testbeds, it would be ideal if the results are "clean" > enough to find out what causes the difference. Than means many of > the tests may lack important attributes like "web" cross traffic -- > although of course there must also be enough tests with cross traffic > to see how the algorithm will perform in practice. Hmmm. My own view would be that any clearly unrealistic test scenarios should be explicitly labeled as such. One of my other views (as expressed in the 2002 Hotnets paper on "Internet Research Needs Better Models") is that a reliance on unrealistic scenarios in evaluating transport protocols (e.g., scenarios with only one-way traffic, only long-lived flows, or only flows all with the same RTT) could do a serious dis-service in the design and evaluation of transport protocols. Thus, my own view would be that test scenarios that were clearly repeatable but clearly unrealistic could do more harm than good, if people were going to rely on that for evaluating transport protocols. But maybe others have a different view, who knows? - Sally http://www.icir.org/floyd/ The 2002 Hotnets paper: http://www.icir.org/models/hotnetsFinal.pdf From lachlan.andrew at gmail.com Mon Nov 5 17:09:08 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Mon, 5 Nov 2007 17:09:08 -0800 Subject: [Tmrg] Round table: level of realism of tests? In-Reply-To: References: <46F98369.8030605@psc.edu> <65b35fd1d6c8959209fe942f1c5ddece@mac.com> Message-ID: Greetings Sally, On 05/11/2007, Sally Floyd wrote: > My apologies for responding a month late on this! > My unanswered email folder has been building up on me. No worries. I know you're really busy. > > Motivated by past debates over different labs' tests, I was also more > > interested in repeatability than realism. If we get different results > > using simulation from dummynet or different results using dummynet > > from real WAN testbeds, it would be ideal if the results are "clean" > > enough to find out what causes the difference. Than means many of > > the tests may lack important attributes like "web" cross traffic -- > > although of course there must also be enough tests with cross traffic > > to see how the algorithm will perform in practice. > > Hmmm. *grin* > My own view would be that any clearly unrealistic test scenarios > should be explicitly labeled as such. Good idea. We could classify tests as those "trying to understand" behaviour vs those "evaluating" behaviour. The first group could usefully have tests which would be misleading if they were in the second group. > One of my other views (as > expressed in the 2002 Hotnets paper on "Internet Research Needs > Better Models") is that a reliance on unrealistic scenarios in > evaluating transport protocols (e.g., scenarios with only one-way > traffic, only long-lived flows, or only flows all with the same > RTT) could do a serious dis-service in the design and evaluation > of transport protocols. True, that is a danger we must try to avoid. It has to be balanced against the need to hold some variables fixed while others are varied. For example, if we're looking at the impact of the number of hops on fairness, there is a case to keep RTTs equal to eliminate the effect of RTT-unfairness for that experiment. We can also do things to maximize repeatability without reducing realism, like agreeing on some deterministic (pseudo-random?) cross traffic rather than every experiment having unique cross traffic. I've always thought of this round-table as only a start, which is why I felt comfortable suggesting having too many "understanding" experiments, at the expense of "evaluating" experiments. But the table is round, so my suggestion won't determine what happens. 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 molnar at tmit.bme.hu Tue Nov 6 02:57:57 2007 From: molnar at tmit.bme.hu (=?ISO-8859-2?Q?S=E1ndor_Moln=E1r?=) Date: Tue, 06 Nov 2007 11:57:57 +0100 Subject: [Tmrg] suggestions on fairness metrics to the TCP evaluation round-table Message-ID: <473048B5.6050108@tmit.bme.hu> Hi All, We have recently completed a project on the fairness analysis of high speed transport protocols. One of our result is that we suggest a new performance metric (saturation time) that can be important from the dynamical aspects of interacting protocols. We have found that the short-term dynamics could have significant impacts on long-term fairness. We hope it is relevant to the topic of TCP evaluation round-table, especially to convergence time. Our results can be found in our downloadable technical report, see below. The website of our project: http://qosip.tmit.bme.hu/~sonkoly/Tcp/ The technical report can be downloaded from: http://qosip.tmit.bme.hu/~sonkoly/Tcp/files/Technical_Report.pdf I also included the abstract of the report. Abstract --------- The short-term dynamics of competing high speed TCP flows could have surprising impacts on their long-term fairness. As a result, this could have a severe impact on the co-existence and, finally, the deployment feasibility of different seemingly promising proposals for the next generation networks. However, to our best knowledge, no root-cause analysis of the observation is available. This is the major motivation of our work. The contribution of the paper is twofold. First, we present our comprehensive performance evaluation results of both inter- and intra-protocol fairness behavior of different TCP versions to get an overall view of these protocols. The analysis has revealed not only the equilibrium behavior but also the transient characteristics with the dynamic behavior. Second, we have performed a root-cause analysis to get a deeper understanding in the case of some of the promising TCP versions. This study not only fills the "black holes", the questions which remained unanswered in some cases but rather goes deeper and investigates questions which have never been asked yet. The analysis spans multiple dimensions: flow-level, packet-level, queueing and spectral analysis. Three loss-based (HighSpeed TCP, Scalable TCP and BIC TCP) approaches and the delay-based FAST are investigated in details with both dumb-bell and parking-lot topologies. Regards, Sandor From mascolo at poliba.it Tue Nov 6 03:02:32 2007 From: mascolo at poliba.it (Saverio Mascolo) Date: Tue, 6 Nov 2007 12:02:32 +0100 Subject: [Tmrg] (no subject) Message-ID: <000601c82064$8f339540$723bccc1@HPSM> what do you mean by "different level of congestion"? sm On 11/6/07, Sally Floyd wrote: > - The rise time of a single flow to an empty systems is not very > interesting, because it many measures the impact of slow start. Actually, the flow completion time in an uncongested system can be a quite interesting thing to measure, particularly if one is evaluating one of the many proposals for start-ups faster than slow-start. (One of these proposals is Quick-Start, RFC 4782; some of the others are discussed in Appendix A of RFC 4782.) I would recommend having scenarios include the case of a generally-uncongested link, as well as including cases with various levels of congestion, with metrics including per-flow transfer times, fairness, and aggregate packet drop rates. This should illustrate some of the good and potentially-bad aspects of protocols with fast start-ups. - Sally http://www.icir.org/floyd/ RFC 4782: http://www.ietf.org/rfc/rfc4782.txt _______________________________________________ Tmrg-interest mailing list Tmrg-interest at ICSI.Berkeley.EDU http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/tmrg-interest/attachments/20071106/4c188372/attachment-0001.html From sallyfloyd at mac.com Tue Nov 6 14:02:06 2007 From: sallyfloyd at mac.com (Sally Floyd) Date: Tue, 6 Nov 2007 14:02:06 -0800 Subject: [Tmrg] (no subject) In-Reply-To: <000601c82064$8f339540$723bccc1@HPSM> References: <000601c82064$8f339540$723bccc1@HPSM> Message-ID: <9bfa0ca77cca000514697fe7682523a5@mac.com> Saverio - > what do you mean by "different level of congestion"? Include "uncongested" scenarios, e.g., with low levels of link utilization. And include highly "congested" scenarios, with high levels of link utilization and a range of packet dropping and/or marking rates. With the "different levels of congestion" produced by scenarios with different levels of traffic. E.g., the number of web sessions started each second, the number of long-lived flows, etc. I don't have a proposal for a single metric that captures the "level of congestion" in congested and uncongested scenarios, however. (It is not clear to me that we need one.) - Sally > On 11/6/07, Sally Floyd wrote: > >> - The rise time of a single flow to an empty systems is not very >> > interesting, because it many measures the impact of slow start. >> >> Actually, the flow completion time in an uncongested system can be >> a quite interesting thing to measure, particularly if one is >> evaluating one of the many proposals for start-ups faster than >> slow-start.??(One of these proposals is Quick-Start, RFC 4782; some >> of the others are discussed in Appendix A of RFC 4782.) >> >> I would recommend having scenarios include the case of a >> generally-uncongested link, as well as including cases with various >> levels of congestion, with metrics including per-flow transfer >> times, fairness, and aggregate packet drop rates.??This should >> illustrate some of the good and potentially-bad aspects of protocols >> with fast start-ups. >> >> - Sally >> http://www.icir.org/floyd/ >> >> RFC 4782:??http://www.ietf.org/rfc/rfc4782.txt >> >> _______________________________________________ >> Tmrg-interest mailing list >> Tmrg-interest at ICSI.Berkeley.EDU >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest > > > - Sally http://www.icir.org/floyd/ From sallyfloyd at mac.com Tue Nov 6 15:21:17 2007 From: sallyfloyd at mac.com (Sally Floyd) Date: Tue, 6 Nov 2007 15:21:17 -0800 Subject: [Tmrg] Round table: level of realism of tests? In-Reply-To: References: <46F98369.8030605@psc.edu> <65b35fd1d6c8959209fe942f1c5ddece@mac.com> Message-ID: >> One of my other views (as >> expressed in the 2002 Hotnets paper on "Internet Research Needs >> Better Models") is that a reliance on unrealistic scenarios in >> evaluating transport protocols (e.g., scenarios with only one-way >> traffic, only long-lived flows, or only flows all with the same >> RTT) could do a serious dis-service in the design and evaluation >> of transport protocols. > > True, that is a danger we must try to avoid. It has to be balanced > against the need to hold some variables fixed while others are varied. > For example, if we're looking at the impact of the number of hops on > fairness, there is a case to keep RTTs equal to eliminate the effect > of RTT-unfairness for that experiment. My assumption would be that if we are looking at a basic test of tradeoffs between bandwidth, delay, and packet drop rates, and we were varying bandwidth, *all* of these basic tests would have realistic scenarios, with a realistic range of RTTs for traffic on the congested link, a realistic range of packet sizes (including 40-byte packets from TCP ACK packets from reverse-path traffic), a realistic distribution of connection sizes, a realistic mix of TCP and UDP traffic, and the like. And that if we were looking at the effect of different levels of reverse-path traffic, all of the other variable would be held fixed at realistic values. That is, I am assuming that we are not creating scenarios for people to use to debug their own congestion control mechanisms. (People seem to be able to do that for themselves.) I am assuming that the *first* priority is to create scenarios to *evaluate* congestion control mechanisms. Our own, and other people's. And I think that requires realistic scenarios, for the most part. > We can also do things to maximize repeatability without reducing > realism, like agreeing on some deterministic (pseudo-random?) cross > traffic rather than every experiment having unique cross traffic. That sounds fine to me. It would certainly be a good thing if different simulators and different testbeds all gave the same *general* results for the same scenario. Certainly, within a single simulator, results should be repeatable. (E.g., in ns-2 version x, with simulation script y, and seed z for the pseudo-random number generator, all users should get the same results. And in a particular testbed, with a particular set of code, and a particular set-up, repeated experiments should get the same results.) However, I assume that there is a limit to the repeatability across different simulators or different testbeds, or between simulators and testbeds. Certainly it would be good for experiments to be done in both simulators and testbeds, and for the overall quantitative results to be the same. As discussed in the 2001 paper on "Difficulties in Simulating the Internet" ("http://www.icir.org/floyd/papers/simulate_2001.pdf"), simulators and testbeds in some cases have different roles to play. E.g., testbeds will probably be more useful for exploring interactions with the various features of commercial routers, firewalls, middleboxes, and the like. And simulators will probably be more useful to the individual research (particularly the one who does not have a testbed at their disposal) to play with a wide range of scenarios, to develop intuition, and to easily explore functionality that is not yet implemented in testbeds or in the real world. So it would be fine with me, for example, if there were some scenarios that would run on testbeds but not in simulators. Or vice versa. > I've always thought of this round-table as only a start, which is why > I felt comfortable suggesting having too many "understanding" > experiments, at the expense of "evaluating" experiments. But the > table is round, so my suggestion won't determine what happens. Great. I will be there pushing for both the "understanding" and the "evaluating" experiments to have as many realistic scenarios as possible. To avoid encouraging researchers to develop an "understanding" that doesn't have much to do with the real world... - Sally http://www.icir.org/floyd/ From sallyfloyd at mac.com Tue Nov 6 15:45:53 2007 From: sallyfloyd at mac.com (Sally Floyd) Date: Tue, 6 Nov 2007 15:45:53 -0800 Subject: [Tmrg] Round table: Buffer sizes In-Reply-To: References: <46F98369.8030605@psc.edu> <65b35fd1d6c8959209fe942f1c5ddece@mac.com> Message-ID: <5c2659a26b4632985c2d18e1afc14ee3@mac.com> (Going back to some October 2 email. Apologies, again...) > If (big if!) physical routers predominantly have > buffers in packets, then I'd prefer to start with a subset of the > core tests which only use buffers in packets. Yep. I would *guess* that most routers can be characterized as having buffers in packets (e.g., having slots for packet headers, with the actual packet stored elsewhere). I don't know for sure, however. Recent experiments show that 26% of DSL hosts tested show a RED-style drop policy on their upstream queues. (Dischinger et al., "Characterizing Residential Broadband Networks', IMC'07, "http://www.imconf.net/imc-2007/papers/imc137.pdf".) So it *is* getting to be time for realistic scenarios to include some form of AQM, as well as Drop-Tail. ... > Motivated by past debates over different labs' tests, I was also more > interested in repeatability than realism. If we get different results > using simulation from dummynet or different results using dummynet > from real WAN testbeds, it would be ideal if the results are "clean" > enough to find out what causes the difference. Than means many of > the tests may lack important attributes like "web" cross traffic -- > although of course there must also be enough tests with cross traffic > to see how the algorithm will perform in practice. > > Once one or two tests have been defined precisely enough to be > repeatable by different labs, it would of course be good to extend to > a "wider core", like the one you describe. I would like to encourage a wider scope, with vaguely-realistic scenarios including a realistic range of connection sizes. And if two testbeds give qualitatively different results, then the troubleshooting of the differences can include simplifying the scenarios one step at a time. ... > Since the TCP algorithms themselves determine the percentages of > traffic, we should specify the traffic in terms of the number of > flows with each MTU, rather than the amount of traffic. How about > specifying 90% of flows use 1500-byte, and 10% of flows use 536-byte? Something like that sounds good to me. Using setsockopt(TCP_MAXSEG) , as suggested by John. And with reverse-path traffic providing the 40-byte ACK packets. - Sally http://www.icir.org/floyd/ From sallyfloyd at mac.com Tue Nov 6 15:50:28 2007 From: sallyfloyd at mac.com (Sally Floyd) Date: Tue, 6 Nov 2007 15:50:28 -0800 Subject: [Tmrg] TCP evaluation suite round-table In-Reply-To: <20A4D241-511A-4F5C-BA72-2E1B96F25689@nokia.com> References: <46DED185.4040408@mail.eecis.udel.edu> <20A4D241-511A-4F5C-BA72-2E1B96F25689@nokia.com> Message-ID: <5dd6578a875f79064b20fad94680d8fe@mac.com> Lars - On Sep 26, 2007, at 12:31 AM, Lars Eggert wrote: > it might make sense to add a one or two test cases that include a GSM > or UMTS access link. I think that would be a great idea. - Sally http://www.icir.org/floyd/ From lachlan.andrew at gmail.com Tue Nov 6 17:22:50 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Tue, 6 Nov 2007 17:22:50 -0800 Subject: [Tmrg] Tweak of schedule for round table Message-ID: Greetings all, To accommodate a request by colleagues who will be attending remotely, I'd like to swap the session on "impact on congestion control" (early afternoon on Thursday) with the one on "convergence time". The new agenda is at . If that is inconvenient for anyone (especially the session leaders, Larry and Sally, or those attending from other time zones), please let me know. 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 downey at allendowney.com Wed Nov 7 07:00:30 2007 From: downey at allendowney.com (Allen Downey) Date: Wed, 7 Nov 2007 10:00:30 -0500 Subject: [Tmrg] (no subject) In-Reply-To: <000601c82064$8f339540$723bccc1@HPSM> References: <000601c82064$8f339540$723bccc1@HPSM> Message-ID: <2890f9510711070700q77b0e1caoa30d0f4d19270a1b@mail.gmail.com> Hi All, I don't think I have the email that started this thread, so I might be out of line. But I wanted to suggest that there are some interesting things that happen in slow start on an uncongested system, depending on the size of the buffer at the bottleneck relative to the bandwidth-delay product. With apologies for this shameless act of self-promotion, I have a paper on this topic that you can download here: http://allendowney.com/research/tcp/downey07tcp.pdf If that's useful, let me know. If not, I'm sorry for jumping into the middle! Cheers, Allen On 11/6/07, Sally Floyd wrote: > > > > > - The rise time of a single flow to an empty systems is not very > > > interesting, because it many measures the impact of slow start. > > > > Actually, the flow completion time in an uncongested system can be > > a quite interesting thing to measure, particularly if one is > > evaluating one of the many proposals for start-ups faster than > > slow-start. (One of these proposals is Quick-Start, RFC 4782; some > > of the others are discussed in Appendix A of RFC 4782.) > > > > I would recommend having scenarios include the case of a > > generally-uncongested link, as well as including cases with various > > levels of congestion, with metrics including per-flow transfer > > times, fairness, and aggregate packet drop rates. This should > > illustrate some of the good and potentially-bad aspects of protocols > > with fast start-ups. > > > > - Sally > > http://www.icir.org/floyd/ > > > > RFC 4782: http://www.ietf.org/rfc/rfc4782.txt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/tmrg-interest/attachments/20071107/2fb9b7e3/attachment.html From h-shimonishi at cd.jp.nec.com Thu Nov 8 08:07:49 2007 From: h-shimonishi at cd.jp.nec.com (Hideyuki Shimonishi) Date: Fri, 09 Nov 2007 01:07:49 +0900 Subject: [Tmrg] convergence time In-Reply-To: References: Message-ID: <5.1.1.8.2.20071109003040.053271e0@mail.jp.nec.com> Hi Lachlan, David, Cesar, and all, The meeting will begin soon. Unfortunately, I could not manage to attend the meeting... Yeah, I agree to the idea that we should look at the aggregate rate, and its convergence, in different level of congestion in realistic environment. But I think we also need to look at fairness of each flow, or distribution of per-flow throughput, as well. Even if the aggregate rate converges, I do not think this means the convergence of each flow. However, looking at the behavior of individual flows in a realistic environment can be difficult, so I think it might be a good idea to look at the distribution of per-flow average throughput. What I mean is the following: 1) Obtain per-flow throughput distributions with a variety of RTTs, hop counts, load levels, and so on. In this case, all flows are long-lived. 2) Obtain per-flow throughput distributions with the very same environment, but flows are mix of short-lived and long-lived. 3) Compare the difference of these distributions, or its COV. I guess 1) could be a measure for fairness, and firendliness also if we mix different kinds of flows, and 3) could be a measure for convergence. If a protocol has good cenvergence, the difference should be smaller. Also, it might be good to see the distribution with only small files or large files. The former reflects slow-start behavior of a protocols, and the latter reflects congestion avoidance behavior. That is why I proposed our tool (literature [7]) and published it at UCLA website. We can do the above testing easier with the tool. Does this sound more realistic measure of convergence, in addition to the ones you have proposed ? I am not sure Cesar will cover this point, but I guess this would be one of the important points we should cover. Thanks, HIDEyuki Shimonishi At 07/10/31 09:18 -0800, Lachlan Andrew wrote: >Greetings David, > >On 28/10/2007, Xiaoliang (David) Wei wrote: > > Another option, to eliminate the dependency to stability and > > timescale, is that we don't study the convergence of current rate. > > Instead, we study the convergence of the aggregate average rate. That is, > > if the instanenous rate of a flow at time t is x(t), we define the > > aggregate average rate of the flow at time t to be > > X(t) = 1/t * sum u=0->t x(u). > > ("sum" can be "integrate" if the time is continous). > >Good idea. > > > Then we study the convergence of the curve X(t) to the "final value". > > This process might be easier as: > > 1. X(t) is easier to measure because we can just look at the amount we > > have transfered from time 0 to time t; > > 2. X(t) converges even x(t) has a limit-cycle oscillation, so it is less > > sensitive to stability > > 3. If x(t) converges fast, X(t) converges fast too. We can still compare > > the convergence with X(t) > > 4. X(t) does have meaning in user-experience. It measures how long the > > users have to participate in the network to get to the desired rate. > >They're all good points. > >The main drawback is that X(t) converges (much) more slowly, since >it always gives some weight to the early rates. If we want to observe >the impact of each of several newly arriving flows, we need to space >them out further if we use X(t) than we do if we use x(t), or else >the transients will interact. > >The time required to find the "final" value could already be quite >long, especially in the case of Reno, which takes hours to reach >equilibrium on large BDP paths. > >What do others think? > >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 ------------------------------------------------------------------- Hideyuki Shimonishi, Ph.D Assistant Manager R&D Unit / System Platforms Research Laboratories, NEC Corporation h-shimonishi at cd.jp.nec.com ------------------------------------------------------------------- From sallyfloyd at mac.com Thu Nov 8 11:44:41 2007 From: sallyfloyd at mac.com (Sally Floyd) Date: Thu, 8 Nov 2007 11:44:41 -0800 Subject: [Tmrg] slides for Sally's discussion at the CalTach meeting Message-ID: <58714c247084b836cc9a5269e3c5fb08@mac.com> http://www.icir.org/floyd/talks/impactOfNewCC.ppt - Sally http://www.icir.org/floyd/ From lachlan.andrew at gmail.com Thu Nov 8 22:29:04 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Thu, 8 Nov 2007 23:29:04 -0700 Subject: [Tmrg] Scenario for convergence time Message-ID: Greetings all, Here is my homework: the "convergence time" scenario. I also realised that we didn't mention a "hop count fairness" scenario, so I put a few thoughts down for that too. Test aims to determine how quickly existing flows make room for new flows. Agreed on: - Start with one flow in "equilibrium", 10% "background traffic", one flow having aborted slow start with window size 2~4 (initial CWND) - "Realistic" mix of RTTs for background traffic - One measure is time for new flow to transmit 10, 100, 1000, 10000 1500-byte packets. (Can be a *single* simulation/experiment, if we know when each byte is received.) My Proposals: - test equal RTTs, new RTT 4 times longer and 4 times shorter than existing. - For equal RTTs and protocols with a loss component: time until window of new flow after window reduction is at least as large as min window of old flow after a reduction To decide: - What statistics of background traffic? - What RTTs? 80 and 120/30? - What bandwidth? All? 100Mbps? - Should it be specified in bytes instead of packets, to make it MTU-agnostic? - Single link only? Multi-bottleneck fairness: Aim: Determine how much less bandwidth is given to a flow using multiple bottlenecks than to a flow with equal RTT using only one of those bottlenecks. - 2, 3 link parking lot - 3 link network with two two-link flows and a three-link flow (and three one-link flows?) Especially important for hybrid loss/delay - three hop ring with overlapping two-hop flows. Need fancy routing? - three link star. Automatic bi-directional traffic. Other issues: - highly skewed RTTs (May not be "typical" but important/realistic/informative special case.) 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 michael.welzl at uibk.ac.at Thu Nov 8 23:57:00 2007 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Fri, 09 Nov 2007 08:57:00 +0100 Subject: [Tmrg] slides for Sally's discussion at the CalTach meeting In-Reply-To: <58714c247084b836cc9a5269e3c5fb08@mac.com> References: <58714c247084b836cc9a5269e3c5fb08@mac.com> Message-ID: <1194595020.3732.19.camel@pc105-c703.uibk.ac.at> Hi, These slides are great! I think that, while it's now common to include at least one or two TCP-friendliness tests based on one scenario in studies about high speed CC variants, there is still too little focus in most current work on the impact that such mechanisms have on other traffic (and therefore I'm cc'ing ICCRG :-) ). Cheers, Michael On Thu, 2007-11-08 at 11:44 -0800, Sally Floyd wrote: > http://www.icir.org/floyd/talks/impactOfNewCC.ppt > > - Sally > http://www.icir.org/floyd/ > > _______________________________________________ > Tmrg-interest mailing list > Tmrg-interest at ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest From cesar at cs.ucla.edu Fri Nov 9 00:00:33 2007 From: cesar at cs.ucla.edu (Cesar Marcondes) Date: Fri, 9 Nov 2007 00:00:33 -0800 Subject: [Tmrg] Scenario for "Impact of New Protocols on Legacy TCP NewReno" Message-ID: <88d780b40711090000l7b2d95b5k2a3b17eae477703a@mail.gmail.com> Dear Round-Table Participants, I've got the "impact of New Protocols on Legacy Congestion Control (TCP NewReno)". Here is the description in plain english along with some discussion context, agreed on, controversial points and to do. The idea is to perform tests over a dumbbell topology and compare the performance of (1) one execution of N homogeneous TCP NewReno flows, and afterwards, using the same seed, (2) one execution of a mixed TCP NewReno + New Protocol flows, where there are N/2 TCP NewReno flows. As the "New Protocol" replaces half of the NewReno flows, it aims to improve the overall utilization (by a certain amount G), but on the other hand, it could harm the throughput (by a certain amount L) of the co-existing NewReno in doing so. Controversial points: + The same seed is the warranty that the same environment will be run in the two executions and thus the only difference is the protocol itself. Round-Table Discussion: + Dr. Sally pointed out in the literature review, a "Bandwidth stolen from TCP" concept [http://www.icir.org/floyd/talks/impactOfNewCC.ppt], slide 8, as a possible metric to evaluate the impact of new protocol on TCP. Cesar complemented saying that he found other proposals similar, in nature, in his literature review. + There was an extra clarification on making the proper distinction between "measure of shareness on mixed flows scenario" by using some fairness metric AND the "measure of the impact", the actual metric described above. Agreed on: + None yet. Todo: + Couple the amount G and L in a either a single metric "L/G"?, or use a 2-D graph to represent the tradeoff of G and L? + What would be a reasonable range on which L could be reduced? Best regards, Cesar Marcondes CS/UCLA From sangtae.ha at gmail.com Fri Nov 9 05:40:43 2007 From: sangtae.ha at gmail.com (SANGTAE HA) Date: Fri, 9 Nov 2007 08:40:43 -0500 Subject: [Tmrg] Scenario for inter-RTT fairness Message-ID: <649aecc70711090540u2416404p6814efa4eb2b00e7@mail.gmail.com> Dear Round-table participants, I've got "Inter-RTT fairness scenario" in the meeting. The scenario proposed here is based on what we have been doing for RTT fairness testing. Scenario: - One flow with a fixed RTT. - The RTT of the other flow is varied. - The bottleneck buffer size is set to some percentage of BDP. - Measure throughput over a second half of a simulation. (This is what Sally suggested in other testing scenarios) - Metric can be either throughput ratio (fairness ratio) or fairness index. To agree on: - Do we need background traffic for inter-RTT fairness test? If so, 10% of background traffic with realistic mix of RTTs? - The range of RTT we are interested in. e.g., One flow has a fixed RTT of 160ms, and the other flow varies its RTT from 10ms to 160ms (10ms, 20ms, 40ms, 80ms, 160ms). - What buffer size in the bottleneck? e.g., 100ms BDP buffer size? Regards, Sangtae From Romaric.Guillier at ens-lyon.fr Fri Nov 9 07:57:56 2007 From: Romaric.Guillier at ens-lyon.fr (Romaric Guillier) Date: Fri, 09 Nov 2007 16:57:56 +0100 Subject: [Tmrg] Scenario "Impact of transient states on CC" Message-ID: <20071109165756.c0rxjyr73vw44wgc@tadorne.ens-lyon.fr> Hi! Here is my proposal for a scenario to test the impact of transient states on CC methods and some points that need to be discussed. Cheers Romaric Guillier -------------- next part -------------- *Scenario transient events Through this scenario, we are trying to evaluate the impact of a sudden change of congestion level on a given congestion control method. We are considering both the case where there is a sudden decrease or increase of the congestion level. This scenario is composed of three parts: the control, the uphill test and the downhill test. The control corresponds to a file transfer of a given volume of data, so as to check the necessary time to complete its transfer without perturbations. The downhill test consists in abruptly applying a given congestion level while a file transfer is occuring, the uphill test is done by starting a file transfer when there is congestion in the system, later the congestion abruptly desappears. *Parameters V, the size of the transfer Cg, the congestion level that is applied to the system *Metrics Aggressiveness = (Tuphill - Tcontrol)/ Tcontrol Responsiveness = (Tdownhill - Tcontrol)/ Tcontrol *Timeline --Control At time = 0, a transfer of size V is started At time = Tcontrol, the transfer completes --Downhill test At time = 0, a transfer of size V is started At time = Tcong, Cg is applied to the system At time = Tdownhill, the transfer completes --Uphill test At time = -1, Cg is applied to the system At time = 0, a transfer of size V is started At time = Tcong, Cg is removed from the system At time = Tuphill, the transfer completes *To be discussed: - Why not putting the uphill/downhill phase during the same transfer ? So that we don't need to ask ourselves questions about convergence and when to switch, we would still need to perform two tests to covert every possibilities - Should we remove the slow start phase ? - How to generate the congestion: *UDP, similar TCP flows (interaction with the interfairness problem), reference TCP flows (interaction with the intra-fairness problem) - Tcong is a function of V(,RTT) : time to transfer X% of V when there is no congestion , time to be well out of the slow start phase, etc.. From sallyfloyd at mac.com Fri Nov 9 09:01:44 2007 From: sallyfloyd at mac.com (Sally Floyd) Date: Fri, 9 Nov 2007 09:01:44 -0800 Subject: [Tmrg] Scenarios for testing delay/throuoghput tradeoffs Message-ID: Here is a first draft on describing possible scenarios for testing delay/throughput tradeoffs for a particular congestion control mechanism. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Delay_throughput.txt Url: http://mailman.ICSI.Berkeley.EDU/pipermail/tmrg-interest/attachments/20071109/32b5f526/attachment.txt -------------- next part -------------- - Sally http://www.icir.org/floyd/ From lars.eggert at nokia.com Fri Nov 9 09:10:39 2007 From: lars.eggert at nokia.com (Lars Eggert) Date: Fri, 9 Nov 2007 09:10:39 -0800 Subject: [Tmrg] p2p stats Message-ID: Here's a link to the p2p stats I mentioned at the Caltech meeting: http://www.ipoque.com/userfiles/file/P2P-Survey-2006.pdf http://www.ipoque.com/media/news/pressrelease_ipoque_241006.html http://www.ipoque.com/media/news/ ipoques_2007_p2p_survey_to_be_presented_at_technology_reviews_emerging_t echnologies_conference_at_mit.html Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/tmrg-interest/attachments/20071109/4e3f198a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/tmrg-interest/attachments/20071109/4e3f198a/attachment-0001.bin From mascolo at poliba.it Fri Nov 16 04:52:06 2007 From: mascolo at poliba.it (Saverio Mascolo) Date: Fri, 16 Nov 2007 13:52:06 +0100 Subject: [Tmrg] Scenarios for testing delay/throuoghput tradeoffs Message-ID: <006a01c8284f$886b7410$723bccc1@HPSM> The paper "performance evaluation and comparison of westwood+, Newreno and vegas tcp" we published in ACM CCR, april 04 issue contains some experience that could be considered. In particular: 1. one single forward connection and on-off-on-off reverse traffic in order to test the effect of reverses traffic (f.i. one reverse TCP of the same flavour) this scenario is to test the effect of reverse traffic that is VERY important becasue it affects the ack flow of the forward TCP connection 2. single bottleneck the sequence number versus time of different connections show how fair is the advancement of each connection. this graph can show strong unfairness and starvation 3. multi bottleneck. this case is quite complex . under high load our experience is that all TCPs performance slow down. best saverio On Nov 9, 2007 6:01 PM, Sally Floyd wrote: Here is a first draft on describing possible scenarios for testing delay/throughput tradeoffs for a particular congestion control mechanism. - Sally http://www.icir.org/floyd/ _______________________________________________ Tmrg-interest mailing list Tmrg-interest at ICSI.Berkeley.EDU http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest -- Prof. Saverio Mascolo Dipartimentio di Elettrotecnica ed Elettronica Politecnico di Bari Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo at poliba.it http://www-dee.poliba.it/dee-w -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/tmrg-interest/attachments/20071116/2edee4a8/attachment.html From lachlan.andrew at gmail.com Wed Nov 21 14:57:53 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 21 Nov 2007 14:57:53 -0800 Subject: [Tmrg] Traffic generators Message-ID: Injong, Thanks for agreeing to look into recent models of file size distribution. Do you have any updates for us? Apart from the marginal distribution, it would be very interesting to know if/how the distribution depends on (a) the bottleneck capacity or (b) the bottleneck utilization. Sangtae, Have you had a chance to study the Harpoon docs yet? I'm pretty sure that it specifies file arrival times and file durations; the "sessions" come and go deterministically (like once per hour), and are meant to model daily variation in load, not "web sessions". Can you confirm that? I'm not meaning to rush either of you -- just keep the dialogue going... Thanks 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 jsommers at cs.wisc.edu Wed Nov 21 17:49:53 2007 From: jsommers at cs.wisc.edu (jsommers at cs.wisc.edu) Date: Wed, 21 Nov 2007 19:49:53 -0600 (CST) Subject: [Tmrg] Traffic generators In-Reply-To: References: Message-ID: <42834.24.59.255.143.1195696193.squirrel@webmail.cs.wisc.edu> Lachlan, Yes, file arrival times and file sizes are specified when generating traffic with Harpoon. Indeed, sessions are intended to mimic longer-time scale variations in traffic volume. They are *not* intended to model anything about the web, or web sessions. Joel (long-time lurker, first-time poster...) > Sangtae, > > Have you had a chance to study the Harpoon docs yet? > > I'm pretty sure that it specifies file arrival times and file > durations; the "sessions" come and go deterministically (like once per > hour), and are meant to model daily variation in load, not "web > sessions". Can you confirm that? > > > I'm not meaning to rush either of you -- just keep the dialogue going... > > Thanks > 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 > From sangtae.ha at gmail.com Wed Nov 21 20:29:21 2007 From: sangtae.ha at gmail.com (SANGTAE HA) Date: Wed, 21 Nov 2007 23:29:21 -0500 Subject: [Tmrg] Traffic generators In-Reply-To: <42834.24.59.255.143.1195696193.squirrel@webmail.cs.wisc.edu> References: <42834.24.59.255.143.1195696193.squirrel@webmail.cs.wisc.edu> Message-ID: <649aecc70711212029w152f1613j4359af70b5214ba3@mail.gmail.com> Lachlan, Joel clarified the scope of Harpoon. Thank you for clarifying this, Joel. Then, somehow we need to consider the other candidate, Tmix, which we discussed at the meeting. Tmix[1] paper says that it supports source-level and session-level replaying of the trace, so it is expected to support both short-lived (HTTP and VoIP) and long-lived (FTP and P2P) flows. The connection vectors which Tmix builds from the trace can be used in NS2 and over testbed, so we can use the same traffic for both environments. But, I recall that the implementation of Tmix for Linux was not ready a year ago (only available for FreeBSD platform at that time). Also it is not clear how many machines are required to generate the traffic based on the trace, which is also important for us. If we get these answers from the authors, we are right before the selection of the traffic generator for TCP testing. I am CCing to Michele, one of the author of this paper, for the latest status of Tmix. Thanks, Sangtae [1] Tmix: A Tool for Generating Realistic TCP Application Workloads in ns-2, http://www.sigcomm.org/ccr/drupal/?q=node/50 > On Nov 21, 2007 8:49 PM, wrote: > Yes, file arrival times and file sizes are specified when generating > traffic with Harpoon. Indeed, sessions are intended to mimic longer-time > scale variations in traffic volume. They are *not* intended to model > anything about the web, or web sessions. From rchertov at purdue.edu Fri Nov 23 09:21:35 2007 From: rchertov at purdue.edu (Roman Chertov) Date: Fri, 23 Nov 2007 12:21:35 -0500 Subject: [Tmrg] Traffic generators In-Reply-To: <649aecc70711212029w152f1613j4359af70b5214ba3@mail.gmail.com> References: <42834.24.59.255.143.1195696193.squirrel@webmail.cs.wisc.edu> <649aecc70711212029w152f1613j4359af70b5214ba3@mail.gmail.com> Message-ID: <47470C1F.5040404@purdue.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have been following the list for a while but have never posted. For my thesis I have created extensions for ns-2 to improve its emulation capabilities. The following paper describes the system that I have built. http://www.cs.purdue.edu/homes/rchertov/papers/global07.pdf Basically, I tied ns-2 and Click modular router to create a traffic generator that can utilize ns-2 traffic models and TCP agents and generate real IP traffic. The generated IP traffic can have many unique addresses. Additionally, the traffic can then be re-injected into the simulator. I have used this to create PackMIME HTTP and mixed TCP and UDP traffic workloads. Roman SANGTAE HA wrote: > Lachlan, > > Joel clarified the scope of Harpoon. Thank you for clarifying this, Joel. > Then, somehow we need to consider the other candidate, Tmix, which we > discussed at the meeting. > > Tmix[1] paper says that it supports source-level and session-level > replaying of the trace, so it is expected to support both short-lived > (HTTP and VoIP) and long-lived (FTP and P2P) flows. The connection > vectors which Tmix builds from the trace can be used in NS2 and over > testbed, so we can use the same traffic for both environments. > > But, I recall that the implementation of Tmix for Linux was not ready > a year ago (only available for FreeBSD platform at that time). > Also it is not clear how many machines are required to generate the > traffic based on the trace, which is also important for us. > > If we get these answers from the authors, we are right before the > selection of the traffic generator for TCP testing. > I am CCing to Michele, one of the author of this paper, for the latest > status of Tmix. > > Thanks, > Sangtae > > [1] Tmix: A Tool for Generating Realistic TCP Application Workloads in > ns-2, http://www.sigcomm.org/ccr/drupal/?q=node/50 > > >> On Nov 21, 2007 8:49 PM, wrote: >> Yes, file arrival times and file sizes are specified when generating >> traffic with Harpoon. Indeed, sessions are intended to mimic longer-time >> scale variations in traffic volume. They are *not* intended to model >> anything about the web, or web sessions. > _______________________________________________ > Tmrg-interest mailing list > Tmrg-interest at ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRwweT8ksiSCF2AYRAmsBAKCR32oz11FXgO7euCVIcn0ADOZYiwCfb8KP 2ttH+vL+mLEx1KS0DEMlxzE= =g4up -----END PGP SIGNATURE----- From sangtae.ha at gmail.com Fri Nov 23 18:09:03 2007 From: sangtae.ha at gmail.com (SANGTAE HA) Date: Fri, 23 Nov 2007 21:09:03 -0500 Subject: [Tmrg] Traffic generators In-Reply-To: <4746F7B0.80107@email.unc.edu> References: <42834.24.59.255.143.1195696193.squirrel@webmail.cs.wisc.edu> <649aecc70711212029w152f1613j4359af70b5214ba3@mail.gmail.com> <4746F7B0.80107@email.unc.edu> Message-ID: <649aecc70711231809r7436185by6a603201b547e340@mail.gmail.com> Jay, Thank you for the answer. One more question about this. Suppose that we extract N connection vectors (Ai, Bi, Ti), which are identified by their (sip, dip) or (sip, sport, dip, dport), Tmix will delegate each connection vector to one of machines in the testbed. Yes, we can distribute these vectors evenly to each machine in the testbed, or can dedicate all connection vectors to only one machine. I just want to know how many connection vectors (or aggregate throughput) can be handled by one commodity hardware (as you listed, 1or 2GHz CPU 1GB RAM server). I can see the number of connections extracted from the UNC trace is around 2500, and my simple calculation from CDFs given in the paper gives < 250Mbps for burst traffic (100Kbps per connection and 2500 connections at this time instance). >From your experience, this traffic can be handled by one or two pairs of machines? :-) I know it highly depends on the socket buffer size for each connection as well as other system specs. Sangtae > It really depends on the capability of the machines. I have used medium grade > machines, ~1GHz CPU 1GB RAM as well as 500MHz CPU with 256 MB RAM, within a lab > network (I have not used tmix in ns2). The idea with tmix is that, given the > original trace, you create a set of connection vectors for each pair of machines > in the network, knowing the target throughput you wish to generate, and the > capability and number of machines in your network. From jaikat at email.unc.edu Fri Nov 23 07:54:24 2007 From: jaikat at email.unc.edu (Jay Aikat) Date: Fri, 23 Nov 2007 10:54:24 -0500 Subject: [Tmrg] Traffic generators In-Reply-To: <649aecc70711212029w152f1613j4359af70b5214ba3@mail.gmail.com> References: <42834.24.59.255.143.1195696193.squirrel@webmail.cs.wisc.edu> <649aecc70711212029w152f1613j4359af70b5214ba3@mail.gmail.com> Message-ID: <4746F7B0.80107@email.unc.edu> Sangtae, I use tmix on FreeBSD and wanted to clarify your question below about "how many machines are required to generate the traffic based on the trace". It really depends on the capability of the machines. I have used medium grade machines, ~1GHz CPU 1GB RAM as well as 500MHz CPU with 256 MB RAM, within a lab network (I have not used tmix in ns2). The idea with tmix is that, given the original trace, you create a set of connection vectors for each pair of machines in the network, knowing the target throughput you wish to generate, and the capability and number of machines in your network. I hope this answers that question, if not I can clarify further. I was not involved in this discussion so, I am not sure what is known and not known to this group about tmix. But I use it on FreeBSD and would be happy to clarify points. Thanks, --Jay. SANGTAE HA wrote: > Lachlan, > > Joel clarified the scope of Harpoon. Thank you for clarifying this, Joel. > Then, somehow we need to consider the other candidate, Tmix, which we > discussed at the meeting. > > Tmix[1] paper says that it supports source-level and session-level > replaying of the trace, so it is expected to support both short-lived > (HTTP and VoIP) and long-lived (FTP and P2P) flows. The connection > vectors which Tmix builds from the trace can be used in NS2 and over > testbed, so we can use the same traffic for both environments. > > But, I recall that the implementation of Tmix for Linux was not ready > a year ago (only available for FreeBSD platform at that time). > Also it is not clear how many machines are required to generate the > traffic based on the trace, which is also important for us. > > If we get these answers from the authors, we are right before the > selection of the traffic generator for TCP testing. > I am CCing to Michele, one of the author of this paper, for the latest > status of Tmix. > > Thanks, > Sangtae > > [1] Tmix: A Tool for Generating Realistic TCP Application Workloads in > ns-2, http://www.sigcomm.org/ccr/drupal/?q=node/50 > > >> On Nov 21, 2007 8:49 PM, wrote: >> Yes, file arrival times and file sizes are specified when generating >> traffic with Harpoon. Indeed, sessions are intended to mimic longer-time >> scale variations in traffic volume. They are *not* intended to model >> anything about the web, or web sessions. > _______________________________________________ > Tmrg-interest mailing list > Tmrg-interest at ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest From jaikat at email.unc.edu Sat Nov 24 04:44:33 2007 From: jaikat at email.unc.edu (Jay Aikat) Date: Sat, 24 Nov 2007 07:44:33 -0500 Subject: [Tmrg] Traffic generators In-Reply-To: <649aecc70711231809r7436185by6a603201b547e340@mail.gmail.com> References: <42834.24.59.255.143.1195696193.squirrel@webmail.cs.wisc.edu> <649aecc70711212029w152f1613j4359af70b5214ba3@mail.gmail.com> <4746F7B0.80107@email.unc.edu> <649aecc70711231809r7436185by6a603201b547e340@mail.gmail.com> Message-ID: <47481CB1.8060702@email.unc.edu> Sangtae, Just fyi, I think this example in the paper is actually quite low in terms of active connections etc. that we've seen and been able to handle in the lab. I've run experiments with 30,000 active connections per second, but of course with a larger number of much slower machines. Now to specifically answer your question, from my experience, I would guess you would need 2 pairs of machines of the class you specify, for the 2500 active connections. This assumes of course highly well-tuned machines in terms of kernel limits. I doubt you'll get away with one pair - the CPU utilization in handling so many connections may get you down, although I checked my experiments and see a (1GHz, 1GB) did handle upto 2500 active connections with under 50% CPU util just fine. As you know, a LOT depends on your trace characteristics. e.g. I am looking at a recently captured UNC trace with less than 2% concurrent connections (rest being sequential connections); but these concurrent connections are carrying 26% of the bytes. This is a separate question I am curious about -- I could not join the round table discussion remotely. So, is there a document that may be released from those discussions? I'd be eager to look at that. Thanks. --Jay. SANGTAE HA wrote: > Jay, > > Thank you for the answer. One more question about this. > > Suppose that we extract N connection vectors (Ai, Bi, Ti), which are > identified by their (sip, dip) or (sip, sport, dip, dport), Tmix will > delegate each connection vector to one of machines in the testbed. > Yes, we can distribute these vectors evenly to each machine in the > testbed, or can dedicate all connection vectors to only one machine. I > just want to know how many connection vectors (or aggregate > throughput) can be handled by one commodity hardware (as you listed, > 1or 2GHz CPU 1GB RAM server). I can see the number of connections > extracted from the UNC trace is around 2500, and my simple calculation > from CDFs given in the paper gives < 250Mbps for burst traffic > (100Kbps per connection and 2500 connections at this time instance). > From your experience, this traffic can be handled by one or two pairs > of machines? :-) I know it highly depends on the socket buffer size > for each connection as well as other system specs. > > Sangtae > > >> It really depends on the capability of the machines. I have used medium grade >> machines, ~1GHz CPU 1GB RAM as well as 500MHz CPU with 256 MB RAM, within a lab >> network (I have not used tmix in ns2). The idea with tmix is that, given the >> original trace, you create a set of connection vectors for each pair of machines >> in the network, knowing the target throughput you wish to generate, and the >> capability and number of machines in your network. From sangtae.ha at gmail.com Sat Nov 24 18:48:07 2007 From: sangtae.ha at gmail.com (SANGTAE HA) Date: Sat, 24 Nov 2007 21:48:07 -0500 Subject: [Tmrg] Traffic generators In-Reply-To: <47481CB1.8060702@email.unc.edu> References: <42834.24.59.255.143.1195696193.squirrel@webmail.cs.wisc.edu> <649aecc70711212029w152f1613j4359af70b5214ba3@mail.gmail.com> <4746F7B0.80107@email.unc.edu> <649aecc70711231809r7436185by6a603201b547e340@mail.gmail.com> <47481CB1.8060702@email.unc.edu> Message-ID: <649aecc70711241848m48898a4jd24b65987c19a95b@mail.gmail.com> Yes, the results of round table discussion will be announced to TMRG. Sangtae On Nov 24, 2007 7:44 AM, Jay Aikat wrote: > > This is a separate question I am curious about -- I could not join the round > table discussion remotely. So, is there a document that may be released from > those discussions? I'd be eager to look at that. Thanks. > --Jay. > From lachlan.andrew at gmail.com Sun Nov 25 16:46:50 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Sun, 25 Nov 2007 16:46:50 -0800 Subject: [Tmrg] Round-table PFLDnet submission In-Reply-To: <019301c82d70$49d23880$c44c1cac@ad.research.nec.com.cn> References: <88d780b40711202345t61072e7ew43de0825a0ffca76@mail.gmail.com> <60BCCD59-CA40-4571-8E19-BFAD2889C56E@nokia.com> <88d780b40711211027g6379ee66i1b91105ac36c255b@mail.gmail.com> <88d780b40711211310q4eaa4654o33879aefd26c4718@mail.gmail.com> <20071122185937.bezjziem15ogkso8@tadorne.ens-lyon.fr> <019301c82d70$49d23880$c44c1cac@ad.research.nec.com.cn> Message-ID: Greetings Wang, On 22/11/2007, Wang gang wrote: > > I think the basic scenarios which we have agreed on is > > Topology: Dumb-Bell with three nodes at each side, > Parking-Lot with up to three bottleneck, > BW, RTT, buffer size settings > Background traffic, cross traffic distributions. > Collected metrics. > > Is that enough? >From memory, the parking-lot was not part of the "basic scenarios" -- that was a separate scenario. They were all dumbbell with three nodes at each side. The "basic scenarios" section will describe which combinations of a) RTT-distribution b) BW c) buffer size (packets? bytes?) d) AQM (RED? Droptail?) d) ratio of forward-traffic to reverse-traffic e) ratio of long-lived flows to transient flows to study. We can study all possible combinations. You, Larry and Lars have the hard job of writing a first-draft of working out how many combinations we can study (in Sally's "three days of simulation") and how we can choose the most representative scenarios. Perhaps start by listing the possible values for each, and then eliminating any combinations that are unlikely (like low BW links with less than one RTT worth of delay). On possibility would then be to choose one or two "typical" set of parameters, and have a set of tests which varies only one of the parameters from that "typical" list. Do the sums to see how many tests you end up with to work out how many "typcial" sets will be needed. What do people on the list think of that approach? 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 cesar at cs.ucla.edu Mon Nov 26 07:34:27 2007 From: cesar at cs.ucla.edu (Cesar Marcondes) Date: Mon, 26 Nov 2007 07:34:27 -0800 Subject: [Tmrg] Round-table PFLDnet submission In-Reply-To: <88d780b40711260732u7cf95f6g6f0b5ab57c164671@mail.gmail.com> References: <88d780b40711202345t61072e7ew43de0825a0ffca76@mail.gmail.com> <60BCCD59-CA40-4571-8E19-BFAD2889C56E@nokia.com> <88d780b40711211027g6379ee66i1b91105ac36c255b@mail.gmail.com> <88d780b40711211310q4eaa4654o33879aefd26c4718@mail.gmail.com> <20071122185937.bezjziem15ogkso8@tadorne.ens-lyon.fr> <019301c82d70$49d23880$c44c1cac@ad.research.nec.com.cn> <88d780b40711260732u7cf95f6g6f0b5ab57c164671@mail.gmail.com> Message-ID: <88d780b40711260734t42c073a0k34a3105d6cc47585@mail.gmail.com> Dear Lachlan, On Nov 25, 2007 4:46 PM, Lachlan Andrew wrote: > On possibility would then be to choose one or two "typical" set of > parameters, and have a set of tests which varies only one of the > parameters from that "typical" list. Do the sums to see how many > tests you end up with to work out how many "typcial" sets will be > needed. What do people on the list think of that approach? I think the general scenario could explore a good sub-space of parameters that fit in a 3-day simulation. I believe that's the right thing to do. > Cheers, > Lachlan Cesar From lachlan.andrew at gmail.com Mon Nov 26 07:54:46 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Mon, 26 Nov 2007 07:54:46 -0800 Subject: [Tmrg] Round-table PFLDnet submission In-Reply-To: <88d780b40711260732u7cf95f6g6f0b5ab57c164671@mail.gmail.com> References: <88d780b40711202345t61072e7ew43de0825a0ffca76@mail.gmail.com> <60BCCD59-CA40-4571-8E19-BFAD2889C56E@nokia.com> <88d780b40711211027g6379ee66i1b91105ac36c255b@mail.gmail.com> <88d780b40711211310q4eaa4654o33879aefd26c4718@mail.gmail.com> <20071122185937.bezjziem15ogkso8@tadorne.ens-lyon.fr> <019301c82d70$49d23880$c44c1cac@ad.research.nec.com.cn> <88d780b40711260732u7cf95f6g6f0b5ab57c164671@mail.gmail.com> Message-ID: Greetings Cesar, On 26/11/2007, Cesar Marcondes wrote: > On Nov 25, 2007 4:46 PM, Lachlan Andrew wrote: > > On possibility would then be to choose one or two "typical" set of > > parameters, and have a set of tests which varies only one of the > > parameters from that "typical" list. Do the sums to see how many > > tests you end up with to work out how many "typcial" sets will be > > needed. What do people on the list think of that approach? > > I think the general scenario could explore a good sub-space of > parameters that fit in a 3-day simulation. I believe that's the right > thing to do. Yes, we should explore a good sub-set. When I said "a set of tests which varies only one of the parameters", I should have said that each test varies a *different* parameter (they don't all just vary the same parameter!). If we have three or four base "typical" scenarios and in each scenario we explore the impact of each parameter (or most parameters), I think that will allow a reasonably varied subset of scenarios to be explored. Do you agree? 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 cesar at cs.ucla.edu Mon Nov 26 08:02:40 2007 From: cesar at cs.ucla.edu (Cesar Marcondes) Date: Mon, 26 Nov 2007 08:02:40 -0800 Subject: [Tmrg] Round-table PFLDnet submission In-Reply-To: <88d780b40711260759v3a6e5fb1p3cf88263a552f23e@mail.gmail.com> References: <88d780b40711211027g6379ee66i1b91105ac36c255b@mail.gmail.com> <88d780b40711211310q4eaa4654o33879aefd26c4718@mail.gmail.com> <20071122185937.bezjziem15ogkso8@tadorne.ens-lyon.fr> <019301c82d70$49d23880$c44c1cac@ad.research.nec.com.cn> <88d780b40711260732u7cf95f6g6f0b5ab57c164671@mail.gmail.com> <88d780b40711260759v3a6e5fb1p3cf88263a552f23e@mail.gmail.com> Message-ID: <88d780b40711260802x6865a17an9d2c7d6513b87e89@mail.gmail.com> Yes, I agree on this approach. On Nov 26, 2007 7:54 AM, Lachlan Andrew wrote: > Greetings Cesar, > > > On 26/11/2007, Cesar Marcondes wrote: > > On Nov 25, 2007 4:46 PM, Lachlan Andrew wrote: > > > On possibility would then be to choose one or two "typical" set of > > > parameters, and have a set of tests which varies only one of the > > > parameters from that "typical" list. Do the sums to see how many > > > tests you end up with to work out how many "typcial" sets will be > > > needed. What do people on the list think of that approach? > > > > I think the general scenario could explore a good sub-space of > > parameters that fit in a 3-day simulation. I believe that's the right > > thing to do. > > Yes, we should explore a good sub-set. > > When I said "a set of tests which varies only one of the parameters", > I should have said that each test varies a *different* parameter (they > don't all just vary the same parameter!). If we have three or four > base "typical" scenarios and in each scenario we explore the impact of > each parameter (or most parameters), I think that will allow a > reasonably varied subset of scenarios to be explored. Do you agree? > > > Cheers, > Lachlan From wanggang at research.nec.com.cn Mon Nov 26 17:03:40 2007 From: wanggang at research.nec.com.cn (Wang gang) Date: Tue, 27 Nov 2007 09:03:40 +0800 Subject: [Tmrg] Round-table PFLDnet submission References: <88d780b40711202345t61072e7ew43de0825a0ffca76@mail.gmail.com> <60BCCD59-CA40-4571-8E19-BFAD2889C56E@nokia.com> <88d780b40711211027g6379ee66i1b91105ac36c255b@mail.gmail.com> <88d780b40711211310q4eaa4654o33879aefd26c4718@mail.gmail.com> <20071122185937.bezjziem15ogkso8@tadorne.ens-lyon.fr> <019301c82d70$49d23880$c44c1cac@ad.research.nec.com.cn> Message-ID: <02b601c83091$59b16bd0$c44c1cac@ad.research.nec.com.cn> Lachlan, I totally agree with your idea. First list some possible combinations, but then suggest a few ones those are typical and could be carried out in the first step. Cheers. ---------------------------------------- ?? / Wang Gang NEC Labs, China 010-62705180 (ext.511) ????????????????1?????A?14? wanggang at research.nec.com.cn -- CONFIDENTIAL------------------------------------------------------- ?????????,????????,???????.????! This email is confidential. Recipient(s) named above is(are) obligated to maintain secrecy and is(are) not permitted to disclose the contents of this communication to others. Thank you! ---------------------------------------------------------------------- ----- Original Message ----- From: "Lachlan Andrew" To: "Wang gang" Cc: "tmrg" Sent: Monday, November 26, 2007 8:46 AM Subject: Re: Round-table PFLDnet submission > Greetings Wang, > > On 22/11/2007, Wang gang wrote: >> >> I think the basic scenarios which we have agreed on is >> >> Topology: Dumb-Bell with three nodes at each side, >> Parking-Lot with up to three bottleneck, >> BW, RTT, buffer size settings >> Background traffic, cross traffic distributions. >> Collected metrics. >> >> Is that enough? > > From memory, the parking-lot was not part of the "basic scenarios" -- > that was a separate scenario. They were all dumbbell with three nodes > at each side. The "basic scenarios" section will describe which > combinations of > a) RTT-distribution > b) BW > c) buffer size (packets? bytes?) > d) AQM (RED? Droptail?) > d) ratio of forward-traffic to reverse-traffic > e) ratio of long-lived flows to transient flows > to study. We can study all possible combinations. > > You, Larry and Lars have the hard job of writing a first-draft of > working out how many combinations we can study (in Sally's "three days > of simulation") and how we can choose the most representative > scenarios. > > Perhaps start by listing the possible values for each, and then > eliminating any combinations that are unlikely (like low BW links with > less than one RTT worth of delay). > > On possibility would then be to choose one or two "typical" set of > parameters, and have a set of tests which varies only one of the > parameters from that "typical" list. Do the sums to see how many > tests you end up with to work out how many "typcial" sets will be > needed. What do people on the list think of that approach? > > 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 Mon Nov 26 22:37:13 2007 From: sallyfloyd at mac.com (Sally Floyd) Date: Mon, 26 Nov 2007 22:37:13 -0800 Subject: [Tmrg] Round-table PFLDnet submission In-Reply-To: <88d780b40711260734t42c073a0k34a3105d6cc47585@mail.gmail.com> References: <88d780b40711202345t61072e7ew43de0825a0ffca76@mail.gmail.com> <60BCCD59-CA40-4571-8E19-BFAD2889C56E@nokia.com> <88d780b40711211027g6379ee66i1b91105ac36c255b@mail.gmail.com> <88d780b40711211310q4eaa4654o33879aefd26c4718@mail.gmail.com> <20071122185937.bezjziem15ogkso8@tadorne.ens-lyon.fr> <019301c82d70$49d23880$c44c1cac@ad.research.nec.com.cn> <88d780b40711260732u7cf95f6g6f0b5ab57c164671@mail.gmail.com> <88d780b40711260734t42c073a0k34a3105d6cc47585@mail.gmail.com> Message-ID: Cesar - > I think the general scenario could explore a good sub-space of > parameters that fit in a 3-day simulation. I believe that's the right > thing to do. My assumption was that the plan was to come up with a basic set of tests that could be run in simulations over two to three days, and that could be run by an experimenter in a testbed with a reasonable amount of effort, with the basic set of tests including not only the general scenario (Part A of the draft paper) but also delay/throughput tradeoffs (Part B), convergence times (Part C), transients (Part D), impact on TCP traffic (Part E), intra-protocol fairness (Part F), and multiple bottlenecks (Part G). Many of the more delailed scenarios, such as the exploration of transients, might be able to be run is a fairly moderate amount of simulation time; e.g., exploring a very small subset of the parameter space for the exploration of transients might be just fine. My suggestion for the "general scenario" would be that we choose the types of congested links to be explored (some characterized purely by bandwidth, with others characterized more broadly as "congested satellite link" or "congested data center link", as I said in my earlier email), and that for each congested link, with the dumbbell topology, we explore that subset of the parameter space that seems somewhat realistic, *and* that seems most likely to cause problems or to illustrate a new set of tradeoffs for proposed congestion control mechanisms. In particular, for each type of congested link, I would suggest that we explore a range of levels of congestion (as that is a fundamental parameter to explore for congestion control mechanisms). For *some* of the types of congested links in the general scenario, we might want to vary the range of RTTs, or the queue management parameters (buffer size, packets or bytes, AQM or Drop-Tail), or the parameter for the heavy-tailed distribution for the transfer sizes, or something else, but given the desire for a core set of simulations/experiments that can be run in a reasonable amount of time, I think we have to leave the task of exploring much of the space as an open research task for someone else, and in this test suite explicitly concentrate on those scenarios that have been shown to be problematic in the past for someone (e.g., for HSTCP, or for delay-based congestion control protocols, or for very aggressive protocols, or for very timid protocols, etc.), or that have been shown to differentiate between different congestion control mechanisms. And as new scenarios are uncovered by researchers that are somewhat realistic and that illustrate a new set of strengths or weaknesses of particular congestion control mechanisms, they can be added to the core set of scenarios. In particular, my own experience is that two or three days of simulation time is not really all that much, and that we are going to have to be rather draconian in fashioning a core set of tests that can all be run by a researcher in a few days of simulations. The basic set of tests to be run in test-beds might be able to be much larger that the set of tests to be run in simulators (particular the subset of tests that explore a high-bandwidth congested link). For the "general scenario" in Section A, it might be necessary pretty early on to propose different subsets of tests for simulations and for testbeds, and to try to prune the proposed tests for simulations down to the essential subset. Take care, - Sally http://www.icir.org/floyd/ From lachlan.andrew at gmail.com Wed Nov 28 12:02:51 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 28 Nov 2007 12:02:51 -0800 Subject: [Tmrg] Round-table PFLDnet submission In-Reply-To: <6629ccb361ac01b8abf0562fc8a996d8@mac.com> References: <88d780b40711202301x2b88638dr825ec577a91d9f31@mail.gmail.com> <6629ccb361ac01b8abf0562fc8a996d8@mac.com> Message-ID: 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 -- 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