From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f99.google.com (mail-la0-f99.google.com [209.85.215.99]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5442821F1E6 for ; Mon, 27 Apr 2015 13:19:58 -0700 (PDT) Received: by lamq1 with SMTP id q1so2492629lam.1 for ; Mon, 27 Apr 2015 13:19:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=bOYor6jOJqbpOeLrzOqPZuXOudSxhxfTom2fEvfDt/M=; b=gt/mf0TOU+wt2uE2Onqjcn2Z7/fsszrvq52hStdE3yAoBbn2rcB0I/XEZm8gnvAvDM dByuP+JDS1RcVhjxIHROqXbJQdjbsnhEM2KtKxRzv4IynptOQ1qLxt6R/sY3y7vYeWBa w4zaF/ReRZtdQ3TgaFv1MeRLKhKVR9pJJ9SIF8ZbOhCilGKKgJ28clTMsGrnfJawSWmu dLWjUZuqA2QtfxuIj/8FqUu5wDC+r/z587OqJAhuYMuqyfEzdJXFEPzXr7dnfEypClUP 3wKiJOnaGz92j6OXNutXqlx/GNVtn52mrXZlcseKNpPrHlL3J/v001woH6G7GWrrj9wj m7kA== X-Gm-Message-State: ALoCoQnIr/p4Xxqz6qgtgj/x93MfLSSwGjKtNH8zxsYpZCdbKdO1UAu/1cmKm4bf6XjsIGvI/nPygPM0OoTfyYqvVqCekAWR1A== X-Received: by 10.194.171.199 with SMTP id aw7mr25096920wjc.64.1430165996675; Mon, 27 Apr 2015 13:19:56 -0700 (PDT) Received: from mail.la.pnsol.com (eu1sys200aog106.obsmtp.com. [207.126.144.121]) by mx.google.com with SMTPS id a9sm1236240wjy.2.2015.04.27.13.19.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 Apr 2015 13:19:56 -0700 (PDT) X-Relaying-Domain: pnsol.com Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob106.postini.com ([207.126.147.11]) with SMTP ID DSNKVT6Z6nuULg5LwPqKpYgCHCzgWu3wo+cP@postini.com; Mon, 27 Apr 2015 20:19:55 UTC Received: from git.pnsol.com ([172.20.5.238] helo=roam.smtp.pnsol.com) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1YmpVP-00030Y-8M; Mon, 27 Apr 2015 21:19:51 +0100 Received: from [172.20.5.109] by roam.smtp.pnsol.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YmpVF-0000A0-3I; Mon, 27 Apr 2015 20:19:41 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Neil Davies In-Reply-To: <87tww122yw.fsf@toke.dk> Date: Mon, 27 Apr 2015 21:19:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87r3r53ncb.fsf@toke.dk> <04A0C729-6E87-49C6-84F7-3428F236CA15@unimore.it> <3DC1A2EA-6DDD-4FF9-AD12-BB509EFB96B8@unimore.it> <30560030-8A86-481D-A310-B3B72C26C368@pnsol.com> <87fv7l3lqo.fsf@toke.dk> <1E4513D8-FAEB-4D51-969E-093FA4929D89@pnsol.com> <87383l3ktd.fsf@toke.dk> <87tww122yw.fsf@toke.dk> To: =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) Cc: bloat Subject: Re: [Bloat] Detecting bufferbloat from outside a node X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 20:20:27 -0000 Toke On 27 Apr 2015, at 13:03, Toke H=F8iland-J=F8rgensen = wrote: > Neil Davies writes: >=20 >> I don't think that the E2E principle can manage the emerging >> performance hazards that are arising. >=20 > Well, probably not entirely (smart queueing certainly has a place). My > worry is, however, that going too far in the other direction will turn > into a Gordian knot of constraints, where anything that doesn't fit = into > the preconceived traffic classes is impossible to do something useful > with. >=20 > Or, to put it another way, I'd like the network to have exactly as = much > intelligence as is needed, but no more. And I'm not sure I trust my = ISP > to make that tradeoff... :( Ah - no such thing as intelligence here - you need to go for = stochastics:=20 there is no-way that E2E (or any other non-local control mechanism, cf = SDN)=20 can respond quickly enough - the system is more "ballistic" (hence the = stochastic dynamics as a better framing) >=20 >> We've seen this recently in practice: take a look at >> http://www.martingeddes.com/how-far-can-the-internet-scale/ - it is >> based on a real problem we'd encountered. >=20 > Well that, and the post linked to from it > = (http://www.martingeddes.com/think-tank/the-future-of-the-internet-the-end= -to-end-argument/), > is certainly quite the broadside against end-to-end principle. Colour = me > intrigued. Yep - direct consequence of packet neutral behaviour ! >=20 >> In someways this is just control theory 101 rearing its head... in >> another it is a large technical challenge for internet provision. >=20 > It's been bugging me for a while that most control theory analysis (of > AQMs in particular) seems to completely ignore transient behaviour and > jump straight to the steady state. Several years ago I calculated how long it would take a gigabit ethernet = (with a 100=20 buffer queue) to reach steady state (be within 1 part in 10^5) when = offered 100%=20 offered load - it was six months! (usual mathematical caveats apply). = Networks are *NEVER* in steady state! We tend to try and make the "predictable" over = 10 seconds - at least beyond 10seconds control theory has a chance! >=20 > -Toke