5 ms·

RFC 1925: The Twelve Networking Truths (1996)

102 points by transpute 3y ago

RedShift1 3y ago
Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. I'm old enough to have lived through this multiple times now :-(
- diogenes4 3y ago
  Not really relevant to networking, but I firmly believe hash tables (and hashing) had a concrete starting point within recorded history, which appears to be January 1953.
  - pncnmnp 3y ago
    Fascinating! I delved into Knuth's "TAOCP Volume 3", specifically the Hashing section, and indeed: > The idea of hashing appears to have been originated by H. P. Luhn, who wrote an internal IBM memorandum in January 1953 that suggested the use of chaining; in fact, his suggestion was one of the first applications of linked linear lists. Unfortunately, I couldn't locate the memo. It seems they never made it public. However, I stumbled upon a nice paper from 1953 in which he discusses enhancing search engines by refining sets - http://jonathanstray.com/papers/Luhn-SearchEngine-1953.pdf http://jonathanstray.com/papers/Luhn-SearchEngine-1953.pdf Knuth also references Arnold I. Dumey, who appears to be the first to describe hash tables in open literature. I was able to retrieve his paper: https://archive.org/details/sim_computers-and-people_1956-12_5_12/page/n5/mode/2up https://archive.org/details/sim_computers-and-people_1956-12.... Dumey initiates with an O(log n) solution using the "twenty questions" game, subsequently explaining how we'd be better off if we could do computation before we access the memory. I found his introduction to the hash function rather intriguing: > A certain manufacturing company had a parts and assemblies list of many thousands of items. A mixed digital and alphabetic system of numbering items was used, of six positions in all. Eight complex machines or assemblies were sold to the public. These had item numbers taken from the general system. In setting up a punch card control system on these eight items it was first proposed to record the entire six digit number for each item. However, examination of the eight assembly numbers disclosed that no two were alike on the fourth digit. It was therefore sufficient, for sorting purposes, merely to record the fourth digit, thereby releasing five badly needed information spaces for other purposes. > This rather extreme case indicates that an examination of the item description may disclose a built-in redunancy which can be used to cut the field down to practical size. He further discusses handling duplicates and introduces chaining: > Adjust the addressing scheme, according to a method which will be described later, to reduce the number of direct addresses, and use the excess locations to store overflows. Put the overflow address at the tail end of stored item information. What the best reduction is varies from case to case. Note that the expectation of the number of accesses to be made goes up when these methods are used. At each access we check by using the complete item description, usually. And discusses how a somewhat efficient hash address can be constructed by diving a prime number and using the remainder: > Consider the item description as though it were a number in the scale of 37 or whatever. Or write it as a binary number by using the appropriate punched tape coding. Divide this number by a number slightly less than the number of addressable locations (the writer prefers the nearest prime). Throw away the quotient. Use the remainder as the address, adjusting to base 10, as the case may be.
- blowski 3y ago
  What is there to be sad about retrying ideas? Maybe the reason they failed the first time is no longer true.
  - spc476 3y ago
    It's not the retrying that's bad, but the hype, that this time, it'll be better! It's almost never better.
  - Arnt 3y ago
    Indeed. Maybe. When people turn up at the IETF and want to repeat a bad idea, that's the kind of thing they say. They say "the reasons why foo was bad don't necessarily apply to bar" while waving their hands. They try try to make it sound as if the reasons actually don't apply, usually without having much idea about what the reasons were.
  - phantomathkg 3y ago
    I think the parent comments indicate s/he experience something bad twice.
  - kstenerud 3y ago
    Because often they DIDN'T fail the first time. It's just that when the next batch of devs decided they needed something, they didn't bother learning from the previous generation, and instead re-did every mistake of the past 30 years, to finally "invent" the already-working approach that had been there for decades. One example that springs to mind is GUI code. We've gone through 3 cycles of that so far (including the original). Another is programming languages.
    - adql 3y ago
      And biggest one is cloud. We went from sending our code to run at mainframe owned by big corporation and leased monthy for a price to sending our code to big corporation to run at not-mainframe for a monthly price
  - cryptonector 3y ago
- deleted 3y ago
  [deleted]
- readthenotes1 3y ago
  Said every old person since the beginning of sentience
jruohonen 3y ago
I am not sure whether they (IETF) have managed to retain their humor, but some great "truths", such as: " With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." "It is always something." "It is more complicated than you think." Then: "This RFC raises no security issues. However, security protocols are subject to the fundamental networking truths." and "The references have been deleted in order to protect the guilty and avoid enriching the lawyers."
- cryptonector 3y ago
  Check the publication date -- specifically the month and day.
  - jruohonen 3y ago
    Ups! :-)
bryancoxwell 3y ago
> With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. Not sure I understand how this applies to networking?
- Waterluvian 3y ago
  Most of them don’t really. They're fairly generic grievances that hard things are hard.
- kamray23 3y ago
  If you try, you'll very likely succeed. You probably shouldn't, though.
  - rusk 3y ago
    “They were so busy trying to figure out if they could, they forgot to ask themselves if they should”
- hyperman1 3y ago
  I saw some forcepoint contraption forcing a MITM proxy to all http traffic by injecting a DLL in each process. With sufficient manpower and infosec mandate, it got implemented just fine. But its incomplete buggy win32 API emulation landed on random applications, crashing them, and automatic updates and https got disabled left and right because the MITM flying over the heads of applications validating their certs
- euroderf 3y ago
  FWIW similar statements have been made regarding the F-4 Phantom fighter jet.
- i_am_a_peasant 3y ago
  You can build systems of unbounded complexity that are functionally correct but are inelegant.
- 3y ago
runiq 3y ago
13. It's always DNS.
- throw0101c 3y ago
  Related: Jeff of the Craft Computing YT channel has an alcoholic flask merch for sale with "In case of DNS" embossed on it: * https://www.craftcomputing.store/product/hip-flask-in-case-of-dns-8oz-/2 https://www.craftcomputing.store/product/hip-flask-in-case-o...
- otabdeveloper4 3y ago
  DNS is nice, it's the only internet protocol that "just works" and doesn't need tuning with obscure Linux-only system parameters. Maybe it's because I don't use bind.
  - marcosdumay 3y ago
    > Maybe it's because I don't use bind. Windows AD is the worst culprit here. Most times when something breaks that can not possibly be linked to DNS, the AD is bridging the failure in some way. That said, yeah, I'd bet the large majority of bind installations are broken too. It's just that DNS really resists failure, and the GP isn't exactly about when it fails.
  - seanhunter 3y ago
    Wow. That's the first time in my 25+-years on the internet I've ever heard someone say that dns "just works".
    - otabdeveloper4 3y ago
      Wait till you find out about the cascading failure modes of TCP. You're in for the ride of your life.
      - seanhunter 3y ago
        I have run TCP/IP networks of thousands of machines before all the automated tooling that's around these days to make this not cause you to loose your sanity. I've seen many of the possible cascading failure modes there are to see at this point[1]. I stand by my claim that DNS is one of the most unreliable parts of the jenga tower though. [1] eg the first time I had root on a unix box I accidentally advertised it as a gateway over bgp and had all the "outbound" tcp traffic for the business park our office was in and a small ISP coming into my box and timing out. Yeah bgp and routing protocols are also common causes of failure, but DNS is worse.
demondemidi 3y ago
I wonder how many rfcs are nonsense like this since there are thousands and thousands and no one reads them all.
- plaugg 3y ago
  Note the publishing date on that RFC. Also (of course) there is a Wikipedia list of funny RFCs, many with a similar publish date: https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...
  - dzign 3y ago
    The first thing I have seen was the date, than I came back searching this comment...
- lanstin 3y ago
  If I haven’t posted this RFC to a new group I am working with, the collaboration is still new and we haven’t fully bonded. This RFC will be true and useful long after TCP is a historical relic.
drdaeman 3y ago
> Internet Order of Old Farts Chef’s kiss
motohagiography 3y ago
Next time I see a terrible comedian I will wonder if they could have been inventing the internet instead. It's strange to read humour from an age when jokes didn't have to be pro level mind blowing to be funny though. Simpler times.

102 points by transpute 3y ago

Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. I'm old enough to have lived through this multiple times now :-(

diogenes4 3y ago
Not really relevant to networking, but I firmly believe hash tables (and hashing) had a concrete starting point within recorded history, which appears to be January 1953.
- pncnmnp 3y ago
  Fascinating! I delved into Knuth's "TAOCP Volume 3", specifically the Hashing section, and indeed: > The idea of hashing appears to have been originated by H. P. Luhn, who wrote an internal IBM memorandum in January 1953 that suggested the use of chaining; in fact, his suggestion was one of the first applications of linked linear lists. Unfortunately, I couldn't locate the memo. It seems they never made it public. However, I stumbled upon a nice paper from 1953 in which he discusses enhancing search engines by refining sets - http://jonathanstray.com/papers/Luhn-SearchEngine-1953.pdf http://jonathanstray.com/papers/Luhn-SearchEngine-1953.pdf Knuth also references Arnold I. Dumey, who appears to be the first to describe hash tables in open literature. I was able to retrieve his paper: https://archive.org/details/sim_computers-and-people_1956-12_5_12/page/n5/mode/2up https://archive.org/details/sim_computers-and-people_1956-12.... Dumey initiates with an O(log n) solution using the "twenty questions" game, subsequently explaining how we'd be better off if we could do computation before we access the memory. I found his introduction to the hash function rather intriguing: > A certain manufacturing company had a parts and assemblies list of many thousands of items. A mixed digital and alphabetic system of numbering items was used, of six positions in all. Eight complex machines or assemblies were sold to the public. These had item numbers taken from the general system. In setting up a punch card control system on these eight items it was first proposed to record the entire six digit number for each item. However, examination of the eight assembly numbers disclosed that no two were alike on the fourth digit. It was therefore sufficient, for sorting purposes, merely to record the fourth digit, thereby releasing five badly needed information spaces for other purposes. > This rather extreme case indicates that an examination of the item description may disclose a built-in redunancy which can be used to cut the field down to practical size. He further discusses handling duplicates and introduces chaining: > Adjust the addressing scheme, according to a method which will be described later, to reduce the number of direct addresses, and use the excess locations to store overflows. Put the overflow address at the tail end of stored item information. What the best reduction is varies from case to case. Note that the expectation of the number of accesses to be made goes up when these methods are used. At each access we check by using the complete item description, usually. And discusses how a somewhat efficient hash address can be constructed by diving a prime number and using the remainder: > Consider the item description as though it were a number in the scale of 37 or whatever. Or write it as a binary number by using the appropriate punched tape coding. Divide this number by a number slightly less than the number of addressable locations (the writer prefers the nearest prime). Throw away the quotient. Use the remainder as the address, adjusting to base 10, as the case may be.
blowski 3y ago
What is there to be sad about retrying ideas? Maybe the reason they failed the first time is no longer true.
- spc476 3y ago
  It's not the retrying that's bad, but the hype, that this time, it'll be better! It's almost never better.
- Arnt 3y ago
  Indeed. Maybe. When people turn up at the IETF and want to repeat a bad idea, that's the kind of thing they say. They say "the reasons why foo was bad don't necessarily apply to bar" while waving their hands. They try try to make it sound as if the reasons actually don't apply, usually without having much idea about what the reasons were.
- phantomathkg 3y ago
  I think the parent comments indicate s/he experience something bad twice.
- kstenerud 3y ago
  Because often they DIDN'T fail the first time. It's just that when the next batch of devs decided they needed something, they didn't bother learning from the previous generation, and instead re-did every mistake of the past 30 years, to finally "invent" the already-working approach that had been there for decades. One example that springs to mind is GUI code. We've gone through 3 cycles of that so far (including the original). Another is programming languages.
  - adql 3y ago
    And biggest one is cloud. We went from sending our code to run at mainframe owned by big corporation and leased monthy for a price to sending our code to big corporation to run at not-mainframe for a monthly price
- cryptonector 3y ago
deleted 3y ago
[deleted]
readthenotes1 3y ago
Said every old person since the beginning of sentience

jruohonen 3y ago

I am not sure whether they (IETF) have managed to retain their humor, but some great "truths", such as: " With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." "It is always something." "It is more complicated than you think." Then: "This RFC raises no security issues. However, security protocols are subject to the fundamental networking truths." and "The references have been deleted in order to protect the guilty and avoid enriching the lawyers."

cryptonector 3y ago
Check the publication date -- specifically the month and day.
- jruohonen 3y ago
  Ups! :-)

bryancoxwell 3y ago

> With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. Not sure I understand how this applies to networking?

Waterluvian 3y ago
Most of them don’t really. They're fairly generic grievances that hard things are hard.
kamray23 3y ago
If you try, you'll very likely succeed. You probably shouldn't, though.
- rusk 3y ago
  “They were so busy trying to figure out if they could, they forgot to ask themselves if they should”
hyperman1 3y ago
I saw some forcepoint contraption forcing a MITM proxy to all http traffic by injecting a DLL in each process. With sufficient manpower and infosec mandate, it got implemented just fine. But its incomplete buggy win32 API emulation landed on random applications, crashing them, and automatic updates and https got disabled left and right because the MITM flying over the heads of applications validating their certs
euroderf 3y ago
FWIW similar statements have been made regarding the F-4 Phantom fighter jet.
i_am_a_peasant 3y ago
You can build systems of unbounded complexity that are functionally correct but are inelegant.
3y ago

runiq 3y ago

13. It's always DNS.

throw0101c 3y ago
Related: Jeff of the Craft Computing YT channel has an alcoholic flask merch for sale with "In case of DNS" embossed on it: * https://www.craftcomputing.store/product/hip-flask-in-case-of-dns-8oz-/2 https://www.craftcomputing.store/product/hip-flask-in-case-o...
otabdeveloper4 3y ago
DNS is nice, it's the only internet protocol that "just works" and doesn't need tuning with obscure Linux-only system parameters. Maybe it's because I don't use bind.
- marcosdumay 3y ago
  > Maybe it's because I don't use bind. Windows AD is the worst culprit here. Most times when something breaks that can not possibly be linked to DNS, the AD is bridging the failure in some way. That said, yeah, I'd bet the large majority of bind installations are broken too. It's just that DNS really resists failure, and the GP isn't exactly about when it fails.
- seanhunter 3y ago
  Wow. That's the first time in my 25+-years on the internet I've ever heard someone say that dns "just works".
  - otabdeveloper4 3y ago
    Wait till you find out about the cascading failure modes of TCP. You're in for the ride of your life.
    - seanhunter 3y ago
      I have run TCP/IP networks of thousands of machines before all the automated tooling that's around these days to make this not cause you to loose your sanity. I've seen many of the possible cascading failure modes there are to see at this point[1]. I stand by my claim that DNS is one of the most unreliable parts of the jenga tower though. [1] eg the first time I had root on a unix box I accidentally advertised it as a gateway over bgp and had all the "outbound" tcp traffic for the business park our office was in and a small ISP coming into my box and timing out. Yeah bgp and routing protocols are also common causes of failure, but DNS is worse.

demondemidi 3y ago

I wonder how many rfcs are nonsense like this since there are thousands and thousands and no one reads them all.

plaugg 3y ago
Note the publishing date on that RFC. Also (of course) there is a Wikipedia list of funny RFCs, many with a similar publish date: https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...
- dzign 3y ago
  The first thing I have seen was the date, than I came back searching this comment...
lanstin 3y ago
If I haven’t posted this RFC to a new group I am working with, the collaboration is still new and we haven’t fully bonded. This RFC will be true and useful long after TCP is a historical relic.

drdaeman 3y ago

> Internet Order of Old Farts Chef’s kiss

motohagiography 3y ago

Next time I see a terrible comedian I will wonder if they could have been inventing the internet instead. It's strange to read humour from an age when jokes didn't have to be pro level mind blowing to be funny though. Simpler times.