[ih] History question -- multi-homing

[Karl Auerbach]

On 9/15/26 12:10 AM, Jack Haverty via Internet-history wrote:

> Re: the question of when these issues first surfaced...here's what I 
> remember:
>
> POLICY ROUTING

Back in the '80's I worked a bit with ... I hope you are sitting down 
... IBM's SNA LU6.2.  It was very much in line with traffic engineered 
paths such as MPLS and ATM in which paths were centrally computed and 
then disseminated to the routing nodes. (SNA also did a lot of protocol 
conversions in the path, so often that pre-computed path focused on a 
protocol-conversion site somewhere in the middle.)

I called this kind of path-nailing "Yenta Networking" after the 
legendary role of a matchmaking Yenta.  (I do believe that this kind of 
arranged client-server binding does have a place on today's net.  My 
memory is also saying to me, in the voice of Dave Bridgham, "don't 
forget the Nimrod proposals" which used IP source routing.)

===

> In the early 1980s Internet, we used such end-middle traffic to create 
> a diagnostic tool called a "Flakeway".

In the last couple of decades I have extrapolated from Jon's "flakeway" 
concept.  I've moved it down a layer, so that it lives down at the 
Ethernet layer, essentially an Ethernet bridge (that does not 
participate in things like Spanning Tree, and forwards some of the 
mysterious frames defined by IEEE such as "Pause".)  (I've also added a 
lot of frame/packet classification so that different kinds of traffic 
can be run through different sequences of "bad things".)

I experimented with digging into packets and changing the contents - I 
demonstrated some of this at an Interop show a couple of decades ago, in 
the Interop Labs, where I injected words in to VOIP sessions (on the RTP 
protocol.)

But that kind of active perturbation of content was hard to do on fast 
links.  (A modern 10G or higher link can move a lot of frames a second - 
in both directions.)  So we moved that into a different test tool.  
  (And we did generalize it to do "fun things" such as a thing we called 
a "constipation engine" - a device to plop in front of busy web servers 
that were being hit with bogus traffic. The device would slow the 
packets from the server, sometimes splitting them, and managing the TCP 
window, so that the attacker would perceive that the connection was open 
and working, but it was very, very, very slow.  Attackers who were 
simply running scripts, aka "script kiddies", would perhaps not notice 
that attack scripts that once took seconds now took hours.)

So in my later stuff I've most dropped back to what I call "basic 
impairments" - latency (fixed and variable), duplication, drop, packet 
re-sequencing, rate limitation.  (All of these have umpteen control 
knobs to vary what is being done, such as statistical distributions of 
variable delay, and change things over time [like changing packet drop 
to emulate a low earth satellite as it rises from the horizon, crosses 
overhead, and descends.)  (I still have older code that can change 
packet contents.)

My latest implementation does the heavy lifting down in the FreeBSD 
kernel, so it can achieve reasonable packet (actually "frame") rates.  
(And doing this stuff can require some heavy lifting from multiple 
processor cores and use a lot of non-pageable, locked-down memory - 
simulating things like earth-to-JWST-delays (more than ten seconds, one 
way), especially if we add latency variation and allow packet 
re-ordering, can burn a lot of memory for a 10G link.)

These have been rather useful tools for developers.  These tools push 
protocol implementations into realms that are not typically found in 
developer lab networks or even the Internet on a good day.

We've pushed a lot of IP stacks over the edge, even the Linux one (it 
can run out of memory for packet reassembly if subjected to some of the 
more perverse patterns of IPv4 fragmentation over a period of time.)  
We've also made some people unhappy - like a phone vendor who had 
hundreds of thousands of phones out that that collapsed when we ran some 
tests of infrequent but legitimate traffic patterns against them.  And I 
remember at one SIPit event I was able to push nearly every 
implementation into the danger zone simply by collecting packets into a 
"dam" for maybe a 0.2 seconds then let that "dam burst" but releasing 
the packets in an order different than arrival.  I also remember one 
very large vendor of servers in which we found that their TCP stack 
properly did congestive back-off, but failed to climb back to speed 
afterwords.

(My favorite one is to re-frame an IP packet into an Ethernet frame that 
is larger than necessary.  A lot of stacks use the Ethernet length 
rather than the IP length and thus end up running into the unknown data 
in that slop space between the end of the IP packet and the end of the 
Ethernet frame.)

         --karl--