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 <[email protected]> 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 > <[email protected]> wrote: >> On 4/6/16, 1:08 PM, "Bloat on behalf of Kelvin Edmison" >> <[email protected] on behalf of [email protected]> >> 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¹t 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 >> -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
