From: Jonathan Morton <chromatix99@gmail.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: Dave Taht <dave.taht@gmail.com>,
ECN-Sane <ecn-sane@lists.bufferbloat.net>,
tsvwg IETF list <tsvwg@ietf.org>
Subject: Re: [Ecn-sane] Fwd: my backlogged comments on the ECT(1) interim call
Date: Wed, 29 Apr 2020 19:03:01 +0300 [thread overview]
Message-ID: <4B98C666-E91C-462D-B039-F084A86040DE@gmail.com> (raw)
In-Reply-To: <537a840b-4c71-4ad2-8421-32c248eb69fa@bobbriscoe.net>
>> As shown in our test results, Flent (which implements the RRUL test) is indeed now capable of tracking the latency experienced by individual TCP flows. It does not do so at the packet level, but at the socket level.
>>
>> Of course it is also possible to capture the traffic and analyse the traces offline, if you really do want packet-level detail.
>
> 1. So, why do you continue to use this approach? It hides all the larger delays underneath a moving average. This seems more designed to hide inconsistent delay results than to measure them. If a real-time application waited only for the median delay before rendering, it would have to discard the 50% of traffic in the upper median! TCP also delivers nothing until the more delayed packets have been delivered to get the stream in order. So median (or mean) delay is a meaningless metric.
Because we are not laser-focused on the five-nines tail of latency as you are, but instead take a broader view that recognises some tradeoffs. For us, the 99th percentile is interesting, but anything beyond that is not worth sacrificing other desirable properties for. And, as I said, we can extract whatever per-packet statistics we like from a packet trace.
The time-series plot, however, tells us much more about the gross behaviour. It tells us, for example, that the reason you have such good five-nines behaviour is because you drop out of slow-start extremely early, so you end up having to grow linearly to the BDP instead of using some faster function. I bet when you get around to implementing Paced Chirping to correct that, you'll find that your five-nines latency takes a hit from the queue pacing the probe trains. That's a prediction I'd like to see tested.
> 2. I also notice you didn't address Dave's point about using short flows as well as long. I don't believe I have ever seen a test from you or PeteH with anything but long flows.
That's mostly a tools problem. Flent doesn't currently have a way to generate that type of traffic and incorporate it into a test run. It's on our todo list though.
- Jonathan Morton
next prev parent reply other threads:[~2020-04-29 16:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAA93jw5g8vMNEoV899tX=89HzHSG5s2E3sGU1EFVdqRkWryCqw@mail.gmail.com>
2020-04-27 19:26 ` Dave Taht
2020-04-29 9:31 ` Bob Briscoe
2020-04-29 9:46 ` [Ecn-sane] [tsvwg] " Sebastian Moeller
2020-04-29 10:32 ` Bob Briscoe
2020-04-29 11:21 ` Sebastian Moeller
2020-04-29 9:49 ` [Ecn-sane] " Jonathan Morton
2020-04-29 13:37 ` Bob Briscoe
2020-04-29 15:07 ` [Ecn-sane] [tsvwg] " Sebastian Moeller
2020-04-29 16:03 ` Jonathan Morton [this message]
2020-05-16 16:32 ` [Ecn-sane] " Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/ecn-sane.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B98C666-E91C-462D-B039-F084A86040DE@gmail.com \
--to=chromatix99@gmail.com \
--cc=dave.taht@gmail.com \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=ietf@bobbriscoe.net \
--cc=tsvwg@ietf.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox