From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <garmitage@swin.edu.au>
Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31])
	(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 4621B21F0F2
	for <bloat@lists.bufferbloat.net>; Thu, 17 Jan 2013 17:23:16 -0800 (PST)
Received: from [136.186.229.44] (garmitage3.caia.swin.edu.au [136.186.229.44])
	by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r0I1NBO3020058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); 
	Fri, 18 Jan 2013 12:23:11 +1100
Message-ID: <50F8A3FF.3090003@swin.edu.au>
Date: Fri, 18 Jan 2013 12:23:11 +1100
From: grenville armitage <garmitage@swin.edu.au>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
	rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1
MIME-Version: 1.0
To: bloat@lists.bufferbloat.net
References: <20130109033920.C47B95B2B40@lawyers.icir.org>
	<12916ad96425700de4a1892ad43f90b1@lang.hm>
In-Reply-To: <12916ad96425700de4a1892ad43f90b1@lang.hm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Bloat] Bufferbloat Paper
X-BeenThere: bloat@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: General list for discussing Bufferbloat <bloat.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/bloat>
List-Post: <mailto:bloat@lists.bufferbloat.net>
List-Help: <mailto:bloat-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Fri, 18 Jan 2013 01:23:16 -0000



On 01/09/2013 16:02, David Lang wrote:
	.[.]
> I really like the idea of trying to measure latency by sniffing the network and watching the time for responses.

Probably tangential, but http://caia.swin.edu.au/tools/spp/ has proven useful to our group for measuring RTT between two arbitrary packet capture points, for symmetric or asymmetric UDP or TCP traffic flows.

Even more tangential, http://dx.doi.org/10.1109/LCN.2005.101 ("Passive TCP Stream Estimation of RTT and Jitter Parameters") might be an interesting algorithm to implement for estimating RTT of TCP flows seen at a single capture point. (This 2005 paper describes an extension of a technique used by tstat at the time.)

cheers,
gja