[Bloat] dslreports bufferbloat tests

[Dave Taht]

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 <justin at dslr.net> 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
> <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
>>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org