From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F11613B2D2 for ; Wed, 20 Apr 2016 02:06:00 -0400 (EDT) Received: by mail-ig0-x22b.google.com with SMTP id f1so119772268igr.1 for ; Tue, 19 Apr 2016 23:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=GIjmXeWwUl4E7jxjfdqGxanHCIZipfOgSEItjTFAGI0=; b=TCebFo62B8h6CgZI+0uZESSBG9wNscByHIRfTq8nHd12FA9EMYMd0oZB0tYSGjQlmS eDH8cV7FVx/TJKbo2iY+4Dz1mVSLHihSDq8TTBcv82bxQgP4lbfbVRY37RDf8uTSugyl kL2Jf4X+zyZGabxSZ/wB9Z9cWi/lCRCT1RVtpgA8ozyDC1UnEI0pNXh2zDUKOh/qQbBr sQJGnPWJ/y1vsIQr3BBx57QIQfLMyyCHDjiaWRpoxmRoUZY/lBy2OIKeYsxW2kJGza4A VZ6DDixtjPcbQxXJKVmt0yZXR0YRlvdlho+mWcTpyLbXZ+I7LzU2CGb7MnIFG8u7+R1A 1BUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=GIjmXeWwUl4E7jxjfdqGxanHCIZipfOgSEItjTFAGI0=; b=flzAlRJKsrrAxXFmAkm0cE9U/GRYSydtak0wXecwLxYZfwPbPn4hAu1dL5QnE9qXcD 88MGGbio+ikX6hj5hROq1wa9XiiZkJ8mOkJsJQWx+g2SirM0wyMQ7EjTa9R5LmtxmD+x CZ3TI4QC5u2yIxlShlHmLOf9CtIyam19fc1sOsYEGJweLMbIfAvHIu/CgjqZTCTAttsc lb0kKSR+UgIY892dXqu63O1KOpmBtG+zu5wIsNGlnbshekwLRSahOok7Fb5eBBfhQhr0 aqNHs2YX7xLV2aFyb0HN3ouMVBVO0TJoH1kVRw64dWJ74UnMp+SGGIpmHt8SMgTL3lwA 72/w== X-Gm-Message-State: AOPr4FWXeGnCnJjRuBfEK9BD4JqqIHBl//qx3w9E3HCyAWtph0iVkDkn2GPqrdqoQBtIMSXmxLT3yeDkDAtiQQ== MIME-Version: 1.0 X-Received: by 10.50.221.67 with SMTP id qc3mr1586080igc.77.1461132360437; Tue, 19 Apr 2016 23:06:00 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.178.102 with HTTP; Tue, 19 Apr 2016 23:06:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Apr 2016 16:06:00 +1000 X-Google-Sender-Auth: XuJmovwRJs-fdZ4-bbY-LdfPdtI Message-ID: From: jb To: "Livingood, Jason" Cc: Kelvin Edmison , Dave Taht , bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] dslreports bufferbloat tests X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 06:06:01 -0000 I'm running experimental captures on one of the speed test servers.. once in while an IP appears to have traffic control doing something. For example.. DONE 71.126.39.162:62753 Packets: 272 Data outbound: 200340 Data inbound: 435 3-way initial RTT 641.267061233521 ms RTTs 908 909 910 921 922 924 935 938 939 940 1167 1170 1169 1174 1187 1188 1186 1187 1187 1193 1205 1207 1196 1197 1201 1203 1206 1207 1213 1214 1373 1374 1375 1377 1380 1384 1396 1397 1384 1385 1392 1394 1386 1390 1393 1396 1398 1401 1408 1413 1406 1408 1408 1412 1417 1429 1429 1430 1434 1435 1435 1436 1436 1450 1450 1451 1445 1446 1456 1457 1584 1585 1595 1596 1596 1598 1597 1608 1605 1607 1610 1613 1599 1608 1608 1622 1622 1623 1623 1634 1627 1628 1628 1630 1639 1637 1634 1641 1640 1638 1628 1634 1631 1633 1638 1635 1633 1625 ms Timestamps not offered inbound TCP cwr_seen inbound TCP ece_seen inbound IP ecn_capable So this particular snap from the first 200 packets of a download there are poor RTTs but it also picked up the IP ecn_capable flag (but not the IP ecn congestion flag) and it picked up the TCP ece and cwr flags on. Before I go and collect statistics, does anyone have any input on what else can be combed out of the captures? the RTTs I'm measuring are calculated (ignoring selective acks) as the gap from the data segment to the first ack that includes it. In this case tcp timestamps was not offered by the client, if it was, I suppose there is more RTT information to be gotten. I suppose I should be analysing the moving window during the transfer as well, to pick up on what the ece/cwr is actually doing. I could just run tcptrace on each complete dump. but I'm trying to only isolate the most important information. thanks -Justin On Fri, Apr 8, 2016 at 4:23 AM, Livingood, Jason wrote: > On 4/6/16, 1:08 PM, "Bloat on behalf of Kelvin Edmison" > > wrote: > > >>I think people focus on packet loss so much because the term is short, >>seemingly conveys a lot of info and is easy to measure. >> >>Given that know how to measure bloat, it strikes me that what is needed >>is a short marketing-style tag for bloat that can be put up against the >>term "packet loss". > > The BITAG has discussed this issue and debated whether to take up a work > item on it, because it is clear that it is not always the case that more > (or any) packet loss is necessarily bad. And Dave Clark and Steve Bauer > have done some good analysis basically saying packet loss measurements > don=C2=B9t really correlate the broadband quality and more work is needed= . > > My sincere hope is that the new FCC broadband label does not encourage > behavior that will lead to a goal of 0% loss, which would quite obviously > be bad in many ways from a performance and quality standpoint and run > counter to all the good AQM-related work. > > Jason >