From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 5402F3B2F0 for ; Wed, 20 Apr 2016 02:10:27 -0400 (EDT) Received: by mail-oi0-x234.google.com with SMTP id k142so31272374oib.1 for ; Tue, 19 Apr 2016 23:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=qHMeNX0W5rTly2k/hdioHBAr4wIB6FqE1ezYq7CQIH0=; b=YPpYlMyVmldZOBDlBeB8ba2qd3R8wUQG1VnoM6gfeMKmLGpVUPT3wb+Vs9f4O4dMDt 6s1UIyt5D3ATq/7g+W57vcljm2PgpqpFFE9VIIhE3Ypn0Mxq3y3vY2ItrwvMsKGPNm1A k/OfpFgOOMiD2SmZZsZmcqZ3w50rHm1n7uI8oGUz1Raor4JUIxHyu2VstkXJBQ07kI99 3ClY1yulqDgfn4rnwHYo2naIgmppZXO181W0qtyO8TNux//TsLB84fAHAzl7U6nx2CS5 82sJc+suVyRCrk84iJxidjls/pfVL+Z0Da5pO2SGKESl8necnf87ep1ywp2IX9LLB4dS PEFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=qHMeNX0W5rTly2k/hdioHBAr4wIB6FqE1ezYq7CQIH0=; b=SRTYJdBd6MdWqkHOLufpRltRkigpTsIRI9iZBQm7Vl8BnFdOE+d4ichnCDVHpnxLFs tYAghV6PrfKLxY9yJ4GNJdAQfNcBlbORLFZB9XOlXDzg2xeL/Ri5UDW2oGRR/Pb0cm1U 96EhjNT8RA9dsdyvvMLKaSqeZ+WjgQPZbCymDmGqRdUGmntOUx50czszdXxUui75yQpH K+phx2Eo/ZtxowGQ6YlC3h/8swjrlZRErFyAC88kJUfFPssA9m3LcZQ19pN2UV4bv/Wi lpMsRBgHhGZBVLbHATFe8/fPes8wey5LyXpI88uh6Tl05SR5crILcP4zbMtYqboOM0Uh 3rIQ== X-Gm-Message-State: AOPr4FXjD/6PvMDvEFwSjSwpDIPj8t0f1eMzZatSql0n+lJhwIKKdFW0e6oEXdJG32q66gSRFKXQFyog0aVRUw== MIME-Version: 1.0 X-Received: by 10.157.52.182 with SMTP id g51mr3161694otc.165.1461132626697; Tue, 19 Apr 2016 23:10:26 -0700 (PDT) Received: by 10.202.79.194 with HTTP; Tue, 19 Apr 2016 23:10:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Apr 2016 23:10:26 -0700 Message-ID: From: Dave Taht To: jb Cc: "Livingood, Jason" , Kelvin Edmison , 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:10:27 -0000 if you would like me to generate a few tests from my location(s), I could (for example) send codel, pie, fq_codel'd flows along with "normal" behaviors.... On Tue, Apr 19, 2016 at 11:06 PM, jb wrote: > 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 neede= d. >> >> 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 obviousl= y >> be bad in many ways from a performance and quality standpoint and run >> counter to all the good AQM-related work. >> >> Jason >> --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org