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<[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...
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
[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://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
[email protected] | -- Mark Twain
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
