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