Hi Dave,
> On Mar 13, 2023, at 19:22, Dave Collier-Brown via Bloat
> <[email protected]> wrote:
>
> On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink
> <[email protected]> wrote:
>
>> [SM] OK, I will bite, how do you measure achievable throughput without
>> actually generating it? Packet-pair techniques are notoriously imprecise and
>> have funny failure modes.
>
>
> When you mention packet-pair techniques, are you referring to Kathleen
> Nichols' passive ping work, or some other correlation scheme?
[SM] I am referring to what I thought was the classical packet pair
method, send two (or more) packets back to back and measure their temporal
distance at the receiver then deduce the actual capacity from looking at
spacing change as a function of the known packet size... so if I sent 2 packets
of 100 units through a path of 100000 units/time with a small bottleneck of 10
units/time in the middle, the packets leave back to back, now they queue behind
the bottleneck and the first starts to squeeze through taking 10 time units
before it can be transmitted further, same for the second packet, now they are
spaces with a distance of 10 time units when they hit the receiver and the
receiver can estimate the bottleneck capacity.
Now I am sure this is the packet-pair for dummies variant and real methods are
a bit more refined, but that is the gist. And it is known not to work robustly
and reliably over the internet (some link technologies actually batch up
packets or some links send packets in parallel*). One can probably make up for
that by a healthy amount of averaging, but doing so makes these capacity
estimates less and less immediate.
Side-note: paced chirping, as far as I understand is a clever extension of this
idea, that suffers from the same problem, that packet pair measurements work
great in the lab. less so over the internet.
Side-side-note: you can extend the same idea also and use packets of different
length to measure capacity. I did that accidentally as part of my old ATM over
head detector approach, where the linear fit of RTT as function of ICMP packet
size correlated really well with the inverse sum of uplink and downlink
capacity IIRC. Which was neat, but useless and it required linear fitting, if
only due to ATM/AAL5's peculiar quantization issues, but I digress.
> I'm interested in the idea of measuring packet timings to our customers as a
> way of detecting short-lived issues, which I find excessively annoying to
> detect and quantify (;-))
[SM] Ag, that might actually work, because you are not aiming for "over
the whole internet" but over a well known segment mostly under your control,
no? I assume you address this with an ISP hat on, not with a content provider
hat on?
Regards
Sebastian
*) e,g. measly DSL links essentially use ODFM and send quite a bunch of bits in
parallel, so even if a DSL link is the capacity bottleneck, our back to back
pair might traverse that link in one fell swoop fooling us about the available
capacity.
>
> --dave
>
> --
> David Collier-Brown, | Always do right. This will gratify
> System Programmer and Author | some people and astonish the rest
>
> [email protected] | -- Mark Twain
>
> CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any
> and all attachments, contains confidential information intended only for the
> person(s) to whom it is addressed. Any dissemination, distribution, copying
> or disclosure is strictly prohibited and is not a waiver of confidentiality.
> If you have received this telecommunication in error, please notify the
> sender immediately by return electronic mail and delete the message from your
> inbox and deleted items folders. This telecommunication does not constitute
> an express or implied agreement to conduct transactions by electronic means,
> nor does it constitute a contract offer, a contract amendment or an
> acceptance of a contract offer. Contract terms contained in this
> telecommunication are subject to legal review and the completion of formal
> documentation and are not binding until same is confirmed in writing and has
> been signed by an authorized signatory.
>
> _______________________________________________
> Bloat mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
