[Bloat] Offtopic: passive ping. was: Researchers Seeking Probe Volunteers in USA

[Dave Collier-Brown]

On 3/13/23 14:50, Sebastian Moeller wrote:
> [EXTERNAL] This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> Hi Dave,
>
>> On Mar 13, 2023, at 19:22, Dave Collier-Brown via Bloat<bloat at lists.bufferbloat.net>  wrote:
>>
>> On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink<starlink at lists.bufferbloat.net>  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...

Aha!  I was unaware of that /entirely/. I guess I could say I'm not 
classically trained (:-))

>   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?

ISP-like service provider, definitely. We're a kind of payment processor 
for folks who pay for their web sites by having us auction off ad 
space.  I'm actually in ML/Ops, but have an interest in anything that 
can mess with our performance (;-))

>
> 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
>>
>> dave.collier-brown at indexexchange.com  |              -- 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
>> Bloat at lists.bufferbloat.net
>> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.bufferbloat.net%2Flistinfo%2Fbloat&data=05%7C01%7C%7C59245dd9ce2f42dae74508db23f3c839%7Cb07c069022b843668d8d7b845d088e18%7C1%7C0%7C638143302165333406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m7iX24gQCPmu%2FLd4%2B5ogy2GGTsnK6FzQw4EwH59ooDA%3D&reserved=0

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown at indexexchange.com  |              -- Mark Twain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20230313/924bed80/attachment.html>