[Bloat] dslreports bufferbloat tests

[jb]

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
<Jason_Livingood at comcast.com> wrote:
> On 4/6/16, 1:08 PM, "Bloat on behalf of Kelvin Edmison"
> <bloat-bounces at lists.bufferbloat.net on behalf of kelvin at edmison.net>
> 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
>