RFC 3194

The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio

📅 published November 2001, from ietf

The Host-Density Ratio for Address Assignment Efficiency ✨

An update on the H ratio 🦋

  • Stream: Network Working Group 💜
  • RFC number: 3194 🎀
  • Authors: A. Durand of SUN Microsystems, and C. Huitema of Microsoft 🫶
  • Category: Informational 🌸
  • Date: November 2001 📅
  • Updates: RFC 1715 ✨

Status of This Memo

This memo is for the Internet community to read as information. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌈

Copyright (C) The Internet Society (2001). All Rights Reserved. 💅

Abstract

okay so this doc gives an update on the "H ratio" from RFC 1715 🧚 it brings in a brand new ratio that the authors say is way easier to understand, and honestly, same 🔥

1. Evaluating the efficiency of address allocation 🌸

okay picture this: a lazy observer might think the number of addressable things in a plan just grows in a straight line with the size of the address 🙈 like, a 10-digit phone plan should fit 10 billion phones, and 32-bit IPv4 addresses should cover 4 billion computers (using the American English billion, so one thousand millions). BESTIE, that is NOT how it works 💀 the 10-digit plan is already stressed out today, and it only handles a few hundred million phones in North America. And the Internet registries started getting way stricter about handing out addresses when there were only a few tens of millions of computers online 😭

addressing plans are usually built like a hierarchy, kind of like nested boxes 📦 in phone land, the first digits pick a region, the next ones pick an exchange, and the last ones pick a subscriber inside that exchange. in computer networks, the most significant bits point to an address range given to a network provider, the next bits point to the network of an organization that provider serves, and then the subnet where the actual computers sit 💜 at every level you have to leave some extra room. you need more digits for the region code than the number of regions right now would need, and more bits in a subnet than the number of computers strictly calls for 🍓 the number of things at each level keeps changing over time because of growth and mobility. and once you run out of room in the current allocation, you have to renumber, which is painful and super expensive 😩 so basically, cramming too many objects into a hierarchical address space makes life harder for both operators and subscribers. main character problems fr 💀

back in 1993, when we were arguing about revising the Internet Protocol, we kept wondering what a reasonable utilization ratio for an addressing plan actually is ✨ that number would help figure out how many computers could join the Internet with the current 32-bit addresses, and help choose the size of the next generation of addresses. the second part is settled now, since IPv6 uses 128-bit addresses 🦋 but the first question still matters, because knowing how much room the current plan has helps predict when it will run out 🔮

early on, the IPNG folks measured efficiency by just dividing the number of allocated addresses by the size of the address space 🧮 it's simple, but it depends heavily on how big the address space is, which is kind of a problem 🙃 the losses at each level of a hierarchy multiply together. so for example, 50% efficiency at each stage of a three-level hierarchy gives an overall efficiency of 12.5% 😭 if we want a real "pain level indicator," we need a ratio that accounts for those multiplying effects 💅

the "H-Ratio" from RFC 1715 measured efficiency as the base 10 logarithm of the number of allocated addresses, divided by the size of the address in bits 🎀 that makes it independent of address size, which is great, BUT its values only run from 0.0 to 0.30103, and typical values sit between 0.20 and 0.28 😵 honestly those numbers are hard to explain to anyone. it's way easier to say "your address bits are used to 83% of their H-Density," and then explain what H-Density means, than to say "you are hitting an H ratio of 0.25" and then have to explain what the range even is 🫠

this memo introduces the Host Density ratio, or "HD-Ratio," as a replacement for the H-Ratio from RFC 1715 🌈 the HD values go from 0 to 1, and they're usually written as percentage points. the authors think this new version is easier to understand and more expressive than the H-Ratio ✨ literally iconic.

2. Definition of the HD-ratio 🧚

when you're looking at an addressing plan that allocates objects, the host density ratio HD is defined as follows:

              log(number of allocated objects)
   HD = ------------------------------------------
         log(maximum number of allocatable objects)

this ratio is defined for any number of allocatable objects greater than 1, and for any number of allocated objects that is greater than or equal to 1 and less than or equal to the maximum number of allocatable objects 🦋 it's usually shown as a percentage, like 70%. it goes from 0 (0%) when there's only one allocation, up to 1 (100%) when every available address has one object assigned to it 💜 also, you can use any logarithm base you want for the calculation, as long as the numerator and the denominator use the same one 🫶

in most cases, you can get the HD-ratio from the H ratio using this formula:

           H
   HD = --------
        log10(2)

3. Using the HD-ratio as an indicator of the pain level 💖

okay so, to check whether the H-Ratio actually predicted the "pain level" a given efficiency causes, RFC 1715 looked at several networks that had hit their capacity limit 🔥 these could be phone networks at the moment they decided to add digits to their numbering plans, or computer networks when their addressing was considered stretched past what was practical 🌸 the idea is that network managers would put off renumbering or changing the protocol until it became just too painful. so the ratio right before the change is a good predictor of what's achievable in practice 🎀 the examples were the following:

  • Adding one digit to all French telephone numbers, going from 8 digits to 9, when the number of phones hit a threshold of 1.0 E+7.
                              log(1.0E+7)
  HD(FrenchTelephone8digit) = ----------- = 0.8750 = 87.5%
                              log(1.0E+8)


                              log(1.0E+7)
  HD(FrenchTelephone9digit) = ----------- = 0.7778 = 77.8%
                              log(1.0E+9)
  • Expanding the number of areas in the US telephone system, which made the phone number effectively 10 digits long instead of "9.2" (the second digit of area codes used to be limited to 0 or 1), for about 1.0 E+8 subscribers 📞
                            log(1.0E+8)
  HD(USTelephone9.2digit) = ------------ = 0.8696 = 87.0 %
                            log(9.5E+9)


                            log(1.0E+8)
  HD(USTelephone10digit)  = ------------ = 0.8000 = 80.0 %
                            log(1E+10)
  • The globally connected physics and space science DECnet (Phase IV) stopped growing at about 15K nodes (meaning new nodes got hidden) in a 16-bit address space 🛰️
                  log(15000)
  HD(DecNET IV) = ---------- = 0.8670 = 86.7 %
                  log(2^16)

from those examples, these addressing systems hit their limits at really close HD-ratio values 🤯 we can also use the same examples to confirm that the HD-ratio, defined as a quotient of logarithms, predicts better than just dividing allocated objects by the size of the address space 😌 in our three examples, the direct quotients were 10%, 3.2% and 22.8%. those are three very different numbers that don't point to any obvious pattern 🙃 the examples suggest that an HD-ratio around 85% and above corresponds to a high pain level, where operators are ready to make drastic decisions 💀

we can also look at the examples and guess that the operators who renumbered their networks were aiming for a pain level they could comfortably support 🧁 right after renumbering, the HD-ratio of the French network was 78%, and the US network was at 80%. this suggests that values of 80% or less are comfortable trade-offs between pain and efficiency 🫶 literally the sweet spot.

Okay bestie, this is the legal bit, but it's actually cute 🎀 Copyright (C) The Internet Society (2001). All Rights Reserved. 💅

You can copy this document and share it with your friends 🫶 You can also make derivative works that comment on it, explain it, or help people implement it, and you can publish and distribute those too, in whole or in part, with no real restrictions. The one condition is that the copyright notice and this paragraph stay on every copy and derivative work 💖

The document itself is off limits for edits, though. You can't change it in any way, like deleting the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: you can make changes when developing Internet standards, where the procedures for copyrights defined in the Internet Standards process must be followed, or when you need to translate it into a language other than English 🌈

The permissions above are perpetual, which means they're forever 🦋 The Internet Society or its successors or assigns will not revoke them.

This document and the information in it are provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to them for keeping the lights on 🧚✨

📦 where this page comes from