[Tmrg] Tmrg-interest Digest, Vol 11, Issue 4
Douglas Leith
doug.leith at nuim.ie
Wed Aug 22 00:26:57 PDT 2007
Re dummynet, my experience these days is that it can run up to 1Gb
using modern hardware. In my experience more of an issue is that end
hosts can still have difficulty at high bandwidth-delay products due
to sack processing overhead etc. and it is this that has placed the
upper limit on test speeds rather than anything else. I'm not sure
where things break these days but it would be easy enough to check.
Doug
On 21 Aug 2007, at 20:00, tmrg-interest-request at ICSI.Berkeley.EDU wrote:
> 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. TCP evaluation suite round-table (Lachlan Andrew)
> 2. Re: TCP evaluation suite round-table (Lachlan Andrew)
> 3. Re: TCP evaluation suite round-table (Lachlan Andrew)
> 4. Re: TCP evaluation suite round-table (Lars Eggert)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 20 Aug 2007 21:19:35 -0700
> From: "Lachlan Andrew" <lachlan.andrew at gmail.com>
> Subject: [Tmrg] TCP evaluation suite round-table
> To: tmrg-interest at ICSI.Berkeley.EDU
> Message-ID:
> <aa7d2c6d0708202119u5366fd43m7e481364af669d5e at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Greetings all,
>
> On 8-9 November, a few of us will be getting together at Caltech for a
> "round table" to try to agree on some basic parameters and metrics for
> TCP evaluation.
>
> We won't try to answer things like "what fairness metric is best", but
> we can agree on some basic parameters. The situation we're trying to
> avoid is:
>
> Group A finds that at 500Mbps, flow 1 reaches 10% of its final
> throughput after 30s
> Group B finds that at 622Mbps, flow 1 reaches 20% of its final
> throughput after 20s
>
> I'll try to have live video-conferencing via VRVS
> <http://www.vrvs.org/Doc/faq.html> so thta those who can't come in
> person can still participate. Unfortunately, our videoconferencing
> room is small, and so physical attendence will probably be limited to
> a dozen or so people. Please let me know if you're interested.
>
> As basic goals, I'd like to come away from the roundtable with:
> - a set of bandwidths that are of interest, say 10, 155, 622, 2500
> Mbps
> - a set of buffer sizes that are of interest, like BDP or 16384
> packets
> - a set of distributions of RTT that are of interest
> - an agreed notion of "convergence time"
> -- e.g., "the average over period x is within y% of the
> final average
> - an agreed notion of "time to converge to fairness"
> -- e.g., "the ratio of averages over period x is within y%
> of the final ratio"
> -- should this metric depend on the final ratio achieved?
> - an agreed notion of "intraflow variability"
> -- e.g., what timescales are of interest?
> - an agreed set of traffic models for background traffic
>
> Injong has added to that list:
> - a measure of total link utilization
> - fluctuation in utilization due to fluctuation in background traffic.
> - What is the per-flow fair bandwidth share?
>
> I think some of those will be "easy", and we can sort them out on the
> list before an interactive meeting, to save time for more debatable
> ones. It would be good if everyone can throw in some ideas for the
> next couple of months so that we can see issues are the hard ones.
>
> It would be good to have a common set of scenarios which could be
> tested by simulation, emulation and real networks. Obviously, the
> simulation is the most flexible, and so it may have a larger set of
> tests, but we can at least simulate the emulated cases.
>
> Ulterior motive: I'd like people also to simulate/emulate the
> scenarios that can also be tested on WAN-in-Lab :)
>
> If this works, we can get more ambitious in a second roundtable
> elsewhere.
>
> Cheers,
> Lachlan
>
> --
> Lachlan Andrew Dept of Computer Science, Caltech
> 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
> Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 20 Aug 2007 21:36:41 -0700
> From: "Lachlan Andrew" <lachlan.andrew at gmail.com>
> Subject: Re: [Tmrg] TCP evaluation suite round-table
> To: tmrg-interest at ICSI.Berkeley.EDU
> Message-ID:
> <aa7d2c6d0708202136j4d47ba15rc975f13306050c2 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Greetings again,
>
> On 20/08/07, Lachlan Andrew <lachlan.andrew at gmail.com> wrote:
>> As basic goals, I'd like to come away from the roundtable with:
>> - a set of bandwidths that are of interest, say 10, 155, 622, 2500
>> Mbps
>>
>> I think some of those will be "easy", and we can sort them out on the
>> list before an interactive meeting, to save time for more debatable
>> ones.
>
> To try my hypothesis, I think that bandwidths should be easy to agree
> on on-list.
>
> Obvious candidates are:
> 10 Mbit/s -- old Ethernet, the right ball-part for current ADSL/cable
> 54Mbit/s -- 802.11a/g
> 100Mbit/s -- Fast Ethernet
> 155Mbit/s -- OC3/STM-1
> 400Mbit/s -- used by Doug and Injong's Dummynet studies (IIRC)
> 622Mbit/s -- OC12/STM-4
> 1000Mbit/s -- GbE
> 2488Mbit/s -- OC48/STM-16
> 9952Mbit/s -- OC192/STM-64
> 10Gbit/s -- 10GbE
>
> Can we assume that Moore's law now allows Dummynet to run at
> 622Mbit/s? If so, I'd strike 400Mbit/s off in favour of OC12.
>
> With my WAN-in-Lab hat on, I'd vote for GbE, OC48 and 10GbE, since we
> have those.
>
> Can we agree on using
>
> 10Mbit/s
> 100Mbit/s
> 622Mbit/s
> 1000Mbit/s
> 2488Mbit/s
> 10Gbit/s
>
> in all simulations/experiments, unless there is a reason to deviate?
>
> Cheers,
> Lachlan
>
>
> --
> Lachlan Andrew Dept of Computer Science, Caltech
> 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
> Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 20 Aug 2007 22:06:38 -0700
> From: "Lachlan Andrew" <lachlan.andrew at gmail.com>
> Subject: Re: [Tmrg] TCP evaluation suite round-table
> To: tmrg-interest at ICSI.Berkeley.EDU
> Message-ID:
> <aa7d2c6d0708202206s3df32b24k672b6ba38ed45f9d at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Greetings again,
>
> On 20/08/07, Lachlan Andrew <lachlan.andrew at gmail.com> wrote:
>
>> - a measure of total link utilization
>
> Again, I think this should be easy to agree on.
>
> Rather than simply measuring total bit/s over the link (which can be
> achieved by inducing congestion collapse), I would advocate using the
> sum of the *receive* rates of the flows using each link.
>
> For multi-link topologies, this would count the rate of multi-hop
> flows multiple times, and so is different from the "total network
> throughput" (sum of all flow rates). It is also more "useful" than
> measuring the total network throughput, since the latter is maximized
> by giving all capacity to any single-hop flows using a link.
>
> Thoughts?
>
> Lachlan
>
> --
> Lachlan Andrew Dept of Computer Science, Caltech
> 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
> Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 21 Aug 2007 12:12:07 +0300
> From: Lars Eggert <lars.eggert at nokia.com>
> Subject: Re: [Tmrg] TCP evaluation suite round-table
> To: l.andrew at ieee.org
> Cc: tmrg-interest at ICSI.Berkeley.EDU
> Message-ID: <E620BA4E-E71A-40BF-8E13-F0A419C90D03 at nokia.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> On 2007-8-21, at 7:36, ext Lachlan Andrew wrote:
>> Can we assume that Moore's law now allows Dummynet to run at
>> 622Mbit/s? If so, I'd strike 400Mbit/s off in favour of OC12.
>
> during my thesis, I found that dummynet doesn't simulate high-
> datarate paths very accurately anymore once the CPU becomes loaded:
>
> However, simulating wide-area Gigabit links with Dummynet
> is problematic [ZEC2003]. Dummynet uses the kernel firewall
> to identify packets for processing, and depends heavily on
> the kernel timers to control when packets leave the
> transmission buffer. Both mechanisms incur significant
> overheads at high data rates. Furthermore, high data rates
> cause high interrupt loads, which can decrease system
> responsiveness and eventually lead to livelock [MOGUL1997].
> Because Dummynet processing occurs at the IP layer, device
> interrupts cause delays that reduce the accuracy of the
> simulation. These delays can also interfere with user-space
> processing, and as a result affect the benchmark processes
> themselves.
>
> [ZEC2003] Marko Zec and Miljenko Mikuc. Real-Time IP Network
> Simulation at Gigabit Data Rates. Proc. International
> Conference on Telecommunications (ConTEL), Zagreb,
> Croatia, June 11-13, 2003.
>
> As you said, Moore's law may have pushed up the region of bandwidth
> that can be accurately simulated, but it'd be good to have some
> verification.
>
> Lars
> -------------- 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/20070821/c6095385/attachment-0001.bin
>
> ------------------------------
>
> _______________________________________________
> 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 11, Issue 4
> ********************************************
More information about the Tmrg-interest
mailing list