I get the nostalgia for old tools and old routers but the industry is
providing better tools for testing TCP and much better hw & network
stacks. One such tool is iperf 2, and it's actively maintained and
released as open source. https://sourceforge.net/projects/iperf2/
TCP is not static either. There is lot of development including new
socket options, CCAs, etc that need testing. Also, single flows are no
longer enough. Each end device likely has dozens, if not more, TCP state
machines active at any one moment in time and are multicore so testing
really needs to be multithreaded and multiflow.
The analytics side needs to support statistical & multivariate analysis.
Libraries like python scikit learn need to be considered in the design.
That's why the flows code based upon python3 is also released as open
source with examples on how to do things like kolmogorov-smirnov CDF
distances.
I see a shortage in network expertise, including staying current with
current transistor designs and silicon, vs a tools issue. Networking
keeps progressing and staying current requires continuous efforts.
Home networks today are embarrassing to me. Our industry is woefully
behind here.
Not trying to be rude, just calling it as I see it.
Bob
On 10/23/23 11:53 AM, Jack Haverty via Nnagain wrote:
On 10/23/23 10:58, Dave Taht via Nnagain wrote:
I wish that the city-dwellers of BEAD so in love with fiber would
insert 70ms of rural delay into all their testing.
FYI, in case someone wants to pursue such real-world testing....
When we were testing TCP/IP software about 40 years ago there was a
similar problem of how to do tests in a lab which realistically
simulated real-world conditions. We created a software tool called
"Flakeway" which enable traffic flows to be delayed, duplicated,
re-ordered, deleted or mangled. That enabled realistic testing even
when the machines being tested were all in a lab connected to the same
LAN.
When we were doing TCP "bakeoffs" at the FTP Software facility we
dreamed of having such a device.
When Steve Casner and I were doing entertainment grade audio/video
back in the late 1990s we discovered that we were in great need of
something like Postel's Flakeway. (Receiving RTP code and codecs,
especially when dealing with multiple lip-synched streams, can be very
sensitive to inter-packet timing and packet reception order - it was
very hard for us to reliably test all the code paths.)
So a few years later I implemented Jon's Flakeway idea, but at layer
2 rather than 3. (It was far from a weekend hack.) I've now gone
through multiple generations of the idea and sell it as a (reasonably
successful) testing product. I'll attach a screen shot so that one
can get an idea of what it does. (Hopefully the mail handler for this
list doesn't get upset with the attachment.)
(We've also got versions that do some protocol tracking and rewrite
packets in "interesting" ways on the fly. We've had some
less-than-fun [for the customer] experiences such as when a phone
vendor wanted us to exercise their IPv6 code but only had their
firmware based IPv4 ready [and 200, 000+ units already in customer
hands]. Within a couple of minutes we had found issues with their TCP
stack - it seems that far too much IP and TCP code was written in C
and used the default signed integer data type rather than unsigned and
thus has troubles when the high order bit in a packet field changes.
Perhaps the must vulnerable protocol on the net is SIP - I sometimes
believe that it should have as its icon a target with an over-large
bullseye with a bunch of arrows in that bullseye.)
--karl--
_______________________________________________
Nnagain mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/nnagain
_______________________________________________
Nnagain mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/nnagain
