From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f98.google.com (mail-la0-f98.google.com [209.85.215.98]) (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 13D4921F194 for ; Mon, 27 Apr 2015 13:13:34 -0700 (PDT) Received: by lamq1 with SMTP id q1so2489397lam.3 for ; Mon, 27 Apr 2015 13:13:32 -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=aoV9aCsZLpJU0udQRoHV8tkdeRFPFA6pu/UghyXzG/8=; b=L3VbVbm75g28LUeCs+I6z+nm9OUozQC00CIWYUSTTylCtsolySsN8m72oYX7d+SMH+ nw+dIfCulwhtlEep4jy1+j+Nrh4MQfq1I6r1dA3rAt1CzZzD2b4QzPQxF2iIns7URYs0 o35eosURxTcXczF49Q5cl8wDHcYOwzGgq3HHVH6uXRkF9iAwRGVeQQ1p3lFVmVCkyir6 69x/rznRfCvVYfWKInc7PH/llfHgVGVIPGfLJFYZhXNsGVXzSe5uUN4h356I2+ZocEaD WwifYPqIbBOVD0L21+RPVV7XwNQTbSpZbl9GXnM7WGtE0fGS294NzkjSVlpBWVYD5NWz Eubw== X-Gm-Message-State: ALoCoQmKekcaA367346Wysa3xEfmmI6tghvWikTWjkaYufENbQ34UF9NbTxo8i0tDzo8dSXavtVnTx4/RZa60ffa+hsrcYGcHQ== X-Received: by 10.180.97.7 with SMTP id dw7mr23840961wib.74.1430165612708; Mon, 27 Apr 2015 13:13:32 -0700 (PDT) Received: from mail.la.pnsol.com (eu1sys200aog117.obsmtp.com. [207.126.144.143]) by mx.google.com with SMTPS id bc1sm1242591wjc.1.2015.04.27.13.13.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 Apr 2015 13:13:32 -0700 (PDT) X-Relaying-Domain: pnsol.com Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob117.postini.com ([207.126.147.11]) with SMTP ID DSNKVT6Ya+oPaTSlzuKzmu4CJ5X4ZJkPp8xz@postini.com; Mon, 27 Apr 2015 20:13:32 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 1YmpPD-0002zT-Nl; Mon, 27 Apr 2015 21:13:27 +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 1YmpP3-00009u-HV; Mon, 27 Apr 2015 20:13:17 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Neil Davies In-Reply-To: Date: Mon, 27 Apr 2015 21:13:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72DB0260-F0DF-426F-A3F3-ECF5D8AF228F@pnsol.com> To: Paolo Valente 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:14:03 -0000 Paolo On 27 Apr 2015, at 12:54, Paolo Valente = wrote: > Thanks for the pointers. As for the epistemological implications of to = my concerns, I must admit that I find them a little bit frightening :) >=20 > After browsing some of the presentations, the relevant component for = my problem seems to be the variability V. However, it is not clear to me = how I can measure or infer it in my situation, i.e., if I cannot: > 1) have any feedback on the user experience; You'll need to consider the =E2=88=86Q|G and the =E2=88=86Q|S as well - = they contribute to the overall delay and that contributes to the = delivered performance. Response time to get to a certain data flow rate = (say for VoD) or recovery from a packet loss (for TCP) etc interact with = all the factors. We've created models (both analytic and experimental) which relate the = delivered =E2=88=86Q (all of its factors) to QoE for various apps > 2) measure the time that elapses between when a time-sensitive = application puts a message in a socket and when that message is actually = sent by the node in a packet; This is why the capture model has to be one of "timed traces" of = "observables" in the TCP model the socket is one location to measure (at = the two ends), the network interfaces would be another > 3) in the opposite direction, measure the time that elapses between = when a packet arrives to the node and when the application receives the = message contained in the packet. Yes, you need to view this in both directions as you need to isloate the = effect of the network transport from the processing (which also has an = influence on the performance) >=20 > On which documents should I concentrate more to better understand this = point? >=20 > Thanks, > Paolo >=20 > Il giorno 27/apr/2015, alle ore 11:54, Neil Davies = ha scritto: >=20 >> Paolo >>=20 >> Yes, it is - there is a whole methodology for detecting this and = associated algebra for manipulation. It has been used at CERN, in = various telcos and in various large scale, real time distributed systems = to relate end user outcomes to the delay/loss characteristics of the = network. >>=20 >> Take a look at http://www.pnsol.com/publications.html, you may find = http://www.pnsol.com/public/PP-PNS-2009-02.pdf as a good starting point. >>=20 >> Neil >>=20 >> On 27 Apr 2015, at 10:48, Paolo Valente = wrote: >>=20 >>> Hi, >>> a network-monitoring company got curious about bufferbloat issues = and asked me to investigate a little bit the following issue (quite = interesting in my opinion). Is it possible to detect, from outside a = node, if the node is bufferbloated? In particular, the only action = allowed would be to observe the packets entering and leaving the node = (plus, of course, their timing). >>>=20 >>> If such a general problem is to hard or impossible to solve, do you = think it is still possible at least to understand, for some type of = application, if the application is experiencing a high latency because = of bloated buffers inside the node? (As above, by just observing packet = flows from outside the node.) >>>=20 >>> Thanks, >>> Paolo >>>=20 >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >>=20 >=20 >=20 > -- > Paolo Valente =20 > Algogroup > Dipartimento di Fisica, Informatica e Matematica =09 > Via Campi, 213/B > 41125 Modena - Italy =20 > homepage: http://algogroup.unimore.it/people/paolo/ >=20