From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nm29-vm0.access.bullet.mail.sp2.yahoo.com (nm29-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 389EC200619 for ; Tue, 6 Nov 2012 12:49:40 -0800 (PST) Received: from [98.139.44.107] by nm29.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Nov 2012 20:49:38 -0000 Received: from [67.195.22.106] by tm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Nov 2012 20:49:38 -0000 Received: from [127.0.0.1] by smtp102.rog.mail.gq1.yahoo.com with NNFMP; 06 Nov 2012 20:49:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1352234977; bh=sd1xA4RiAuOJLQNUAaifB3L+adsoxI7V+HMeA9j0DqY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=prYrHbkMj+wDjFe0LCmKDNjeA4kO0d2kqGOnv66HLrmUNmW/37AGpD9P+NJQqrsHbK+yMIU7OyGdr/ObE46LiZ5p4msihxPCefpzXoA8t1MkaVrNNKmrp2KArm1wGm9oz4Wct/W3u2S8dJzfsRaANxAE2OQamh4Pcwj7RtHipPs= X-Yahoo-Newman-Id: 930923.20443.bm@smtp102.rog.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: __k7x1sVM1m9DTWEh2JIQq.9A9HMbwgmiklu7VLBZJYpPr3 iNucSP4E9oAUax6Oxnl3vCfu3QLgOeH59cRnFhq3meAtQWGP1K_DFFMuZ72K oTkEop.w_FknmKwj0LvCG3B.dcL3fsd7PRoJIYpNfGslpssx5y4_GAdyBdiZ doikTuRaoWIeb_yZnPymgaKM55JSJl2LM46NzQMqbj.FQAuGs7GioQCUbtbU LCJnZ5fIY6PYRZkdCAGDtcqnkUBLk3lKl5FKDQOeB4xW8jwnMryrhZVKrV8j ci8rEGHLuhvxX4K8b.irA88_5j34NwWtdC11s.d._KJXdCFBJ7wvgLYJKVso cVhO8khvgDsHjrYDQh5s9CyAVeT75vzEoH..U2GmA1EhEibCmjAfSDOpKpMF oXFRivi6Uk09mlxcvn5ZGy5cSgw.vaNNISB2OUdwlzoRAmg59OgHl.CPg_MT DuTqsPcoxYTRLE.VgWAQ- X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- Received: from [192.168.11.45] (davec-b@216.13.131.9 with plain) by smtp102.rog.mail.gq1.yahoo.com with SMTP; 06 Nov 2012 20:49:37 +0000 UTC Message-ID: <5099788B.1000704@rogers.com> Date: Tue, 06 Nov 2012 15:52:27 -0500 From: David Collier-Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: codel@lists.bufferbloat.net References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Codel] RFC: Realtime Response Under Load (rrul) test specification X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: davecb@spamcop.net List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 20:49:40 -0000 Dave Taht wrote: > I have been working on developing a specification for testing networks > more effectively for various side effects of bufferbloat, notably > gaming and voip performance, and especially web performance.... as > well as a few other things that concerned me, such as IPv6 behaviour, > and the effects of packet classification. > > A key goal is to be able to measure the quality of the user experience > while a network is otherwise busy, with complex stuff going on in the > background, but with a simple presentation of the results in the end, > in under 60 seconds. Rick Jones replied: | Would you like fries with that? | | Snark aside, I think that being able to capture the state of the user | experience in only 60 seconds is daunting at best. Especially if | this testing is going to run over the Big Bad Internet (tm) rather | than in a controlled test lab. > This portion of the test will take your favourite website as a target > and show you how much it will slow down, under load. | Under load on the website itself, or under load on one's link. I | ass-u-me the latter, but that should be made clear. And while the | chances of the additional load on a web site via this testing is | likely epsilon, there is still the matter of its "optics" if you will | - how it looks. Particularly if there is going to be something | distributed with a default website coded into it. This, contraintuitive as it might sound, is what will make the exercise work: an indication as a ratio (a non-dimensional measure) of how much the response-time of a known site is degraded by the network going into queue delay. We're assuming a queuing centre, the website, that is running at a steady speed and load throughout the short test, and is NOT the bottleneck. When we increase the load on the network, it becomes the bottleneck, a queue builds up, and the degradation is directly proportional to the network being delayed. A traditional measure in capacity planning is quite similar to what you describe: the "stretch factor" is the ratio of the sitting-in-a-queue delay to the normal service time of the network. When it's above 1, you're spending as much time twiddling your thumbs as you are doing work, and each additional bit of load will increase the delay and the ratio dramatically. I don't know if this will reproduce, but this, drawn as a curve against load, the ratio you describe will look like a hockey-stick: ............................./ 3.........................../ .........................../ ........................../ 2......................../ ......................../ ......................./ 1....................- ._________---------- 0....5....10....15....20....25 Ratio is the Y-axis, load is the X, and the periods are supposed to be blank spaces (;-)) At loads 1-18 or so, the ratio is < 1 and grows quite slowly. Above 20, the ratio is >> 1 and grows very rapidly, and without bound The results will look like this, and the graphic-equalizer display will tell the reader where the big components of the slowness are coming from. Pretty classic capacity planning, by folks like Gunther. Of course, if the web site you're measuring gets DDOSed in the middle of the test, Your Mileage May Vary! --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain (416) 223-8968