Computer Network Performance: Latency, Jitter, Loss, Throughput, and Capacity

Understand how to evaluate network performance through latency, jitter, loss, throughput, goodput, utilization, queues, capacity, and application behavior, with design, measurement, and acceptance criteria.

Check it out!

Computer network performance is the ability of the infrastructure to carry the required traffic flows with useful data rate, delay, delay variation, loss, and availability compatible with application requirements. It is not enough for an interface to operate at 1, 10, or 100 Gb/s: the actual experience depends on the complete path, queues, concurrent load, packet size, physical and logical architecture, hosts, and protocol behavior.

A network can have high nominal bandwidth and still exhibit low throughput, retransmissions, jitter, or increasing latency under load. Performance should therefore be treated as an engineering discipline: requirements need to be defined before design, measured with a reproducible methodology, and verified during operation and acceptance.

The purpose of this article is to establish that foundation: what to measure, why the metrics are interrelated, how architecture affects the result, and how to turn performance into a verifiable requirement. Diagnosing a network that already exhibits slowness or instability is a complementary but distinct problem.

What Defines Network Performance?

The performance perceived by an application results from the interaction among the source, destination, and every element along the path. Between two hosts there may be switches, routers, firewalls, Wi-Fi controllers, WAN links, tunnels, load balancers, cloud services, and independent queues. Each element can add delay, impose a maximum capacity, drop packets, or change how flows compete for resources.

For this reason, the analysis should not be reduced to the question “what is the link speed?”. It is necessary to distinguish nominal capacity, utilization, throughput, goodput, latência, jitter, perda, retransmissions and availability.

The architecture should also consider the behavior of Network Traffic: flows, load, broadcast, multicast, and capacity, because a link rarely carries only one isolated service.

Capacity, Bandwidth, and Utilization

A link’s capacity represents the nominal data rate supported by the medium and technology. Utilization represents how much of that capacity is being demanded over a given interval. A high-capacity link can experience congestion over short intervals even when the five-minute average appears low.

This occurs because network traffic is variable. Backups, transfers, updates, video streams, synchronizations, and simultaneous responses can form microbursts that fill buffers and cause drops before the aggregate average reveals saturation.

Capacity measurement must therefore consider the time window, traffic direction, and exact point along the observed path.

Throughput and Goodput

Throughput is the rate actually transferred along the path over a given interval. It may be lower than the nominal speed because of protocol overhead, contention, loss, retransmission, host limitations, transport-window constraints, firewall processing, or other restrictions.

Goodput represents the truly useful portion delivered to the application, excluding retransmissions and overhead that do not constitute useful data. This distinction matters because a link can be heavily utilized yet deliver little value to the application if a significant portion of capacity is consumed by retransmissions or unnecessary traffic.

Latency and RTT

Latency is the delay between source and destination. Depending on the method, one-way delay or round-trip time (RTT). RTT includes the outbound and return paths as well as processing times encountered along the path.

Delay components include:

• propagation through the physical medium;
• bit serialization on the link;
• processing in hosts and network equipment;
• queuing;
• inspection by firewalls or security functions;
• tunnels, proxies, and intermediary services;
• distance and WAN or cloud architecture.

The most variable component in congested networks is usually queueing delay. A network may therefore show stable RTT at low load and a significant increase as links approach saturation.

Jitter or Delay Variation

Jitter is the variation in packet delay over time. Interactive applications and real-time flows are particularly sensitive to this variation because they need to reproduce audio, video, or control signals at a predictable cadence.

Playback buffers can absorb part of the variation, but they add delay. There is therefore no trade-off-free optimization: increasing the buffer can reduce noticeable playback disruptions, but it also increases end-to-end latency.

Packet Loss and Retransmission

Packets may be dropped because of full queues, physical errors, policies, radio-frequency problems, interface faults, or other mechanisms. The effect of loss depends on the protocol and application.

In TCP, loss can trigger retransmissions and reduce the sending rate according to congestion-control mechanisms. In UDP, the network does not automatically retransmit a lost datagram; the application decides whether to recover, conceal, or simply accept the loss.

For this reason, “1% loss” does not have the same impact on every application. The requirement should derive from the service and protocol behavior, not from a generic number applied across the entire network.

Metrics That Should Be Evaluated Together

No single metric describes complete performance. A coherent measurement combines indicators from the link, path, transport, and application layers.

Metric	What it represents	What it can reveal
capacidade nominal	technological limit of the link	theoretical ceiling of the segment
utilização	portion of capacity being demanded	sustained saturation or peaks
throughput	rate actually transferred	practical capacity of the path
goodput	useful data delivered to the application	actual transfer efficiency
latency/RTT	transit and return time	distance, queues, and processing
jitter	delay variation	temporal instability of queues
loss	undelivered packets	congestion, errors, or policies
TCP retransmissions	resent data	loss, reordering, or timeout
interface errors/discards	faults recorded by the equipment	physical layer, queue, or configuration
CPU/memory	processing resource	possible equipment limitation
queues/queue drops	occupancy and drops by class	contention and QoS
Wi-Fi airtime and retries	medium utilization and retries	interference, coverage, or density

The Network Monitoring provides the continuous metrics layer; NetFlow and flow analysis help explain who is consuming the path; and FCAPS-based Network Management organizes performance as part of operations.

Congestion, Queues, and Buffers

Congestion occurs when traffic demand for a given resource exceeds the capacity available at that instant. That resource may be a physical interface, an egress queue, a firewall, a tunnel, a Wi-Fi radio, a CPU, or a WAN link.

When packets arrive faster than they can be transmitted, they enter a queue. As the queue grows, latency increases. If the buffer is exhausted, packets are dropped. Therefore, increasing latency under load can be a sign of congestion before packet loss appears.

Buffer Is Not Capacity

Buffers absorb temporary differences between arrival and departure rates. They are necessary, but they do not turn a slow link into a fast one. Excessive buffering can allow very long queues, increasing latency for interactive applications during large transfers — a phenomenon frequently associated with bufferbloat.

Queue architecture should be analyzed together with QoS, transport behavior, and traffic-flow profiles.

Microbursts

Microbursts are very short traffic peaks. They can saturate an interface for milliseconds or less, cause drops, and disappear before tools using spaced polling intervals record high average utilization.

This is one reason performance troubleshooting should not rely exclusively on aggregated graphs. Drop counters, high-frequency telemetry, packet capture, and traffic-pattern analysis can reveal phenomena hidden by averages.

Interface Imbalance and Oversubscription

When multiple access ports converge on uplinks with lower aggregate capacity, there is oversubscription. This is not necessarily an error: networks are designed on the assumption that not all users transmit at peak rate simultaneously. The problem arises when the aggregation ratio does not match actual application behavior.

A simple imbalance, such as traffic from several fast links converging on a single slower egress, creates a predictable contention point. Analysis should be performed by direction and for the worst plausible concurrency scenario.

Packet Rate, Packet Size, and Equipment Capacity

Evaluating only gigabits per second can hide another limitation: packets per second (pps). A device processes many more headers to carry the same number of bits when packets are small.

Switches, routers, and firewalls can have different limits for bit throughput, forwarding rate, concurrent sessions, new connections per second, table sizes, cryptographic inspection, and enabled features. A datasheet needs to be interpreted in the context of the function the equipment will perform.

Features such as ACLs, NAT, VPN, IDS/IPS, Layer 7 inspection, telemetry, and QoS can change effective performance depending on platform architecture. Sizing should therefore consider the actual intended configuration, not only the highest marketing figure published.

TCP Throughput, RTT, and Bandwidth-Delay Product

TCP transfer performance depends on the interaction among path capacity, RTT, loss, receive window, congestion control, and host capabilities.

The Bandwidth-Delay Product (BDP) expresses the amount of data that can be “in flight” on a path: approximately the path capacity multiplied by RTT. On high-capacity, high-RTT links, a small window can prevent a single session from using all available bandwidth.

This explains why a test between two nearby hosts can saturate a link while the same application across continents delivers a much lower rate even without local congestion.

RFC 6349 proposes a specific framework for TCP throughput testing and reinforces that evaluating nominal capacity alone is insufficient.

QoS: Priority Does Not Create Bandwidth

Quality of Service organizes traffic handling when contention occurs. Classification, marking, queues, scheduling, policing, and shaping make it possible to differentiate flows according to requirements.

The article What Is QoS? examines these mechanisms in more detail, but one principle must be clear: QoS does not create additional capacity. It determines how limited capacity will be distributed during periods of contention.

Classification and Marking

The policy needs to identify classes with operational meaning. Voice, interactive video, control applications, corporate traffic, backup, and update traffic should not be classified merely for technical convenience; classification should reflect service requirements.

The DSCP field can carry a marking, but the marking has an effect only if equipment along the path trusts it and has consistent queueing behavior configured.

Policing and Shaping

Policing limits rate and may drop or remark excess traffic. Shaping controls the egress rate and normally uses a queue to smooth transmission. They are different mechanisms and can produce different effects on latency and loss.

QoS Must Be Validated Under Contention

Testing QoS without creating competition among classes proves little. The acceptance scenario should generate enough load to activate the queues and confirm that critical traffic receives the intended treatment without causing unexpected effects on other classes.

Physical Architecture and Performance

A well-designed logical network does not compensate for deficiencies in the physical infrastructure. The physical layer needs to provide margin, signal integrity, compatible links, and stable power.

Structured Cabling

Installation defects, connectors, crosstalk, return loss, excessive length, bend radius, or interference can introduce errors and retransmissions. An Ethernet link that comes “up” is not automatically validated for the intended category and application.

Cabling certification should demonstrate the parameters applicable to the link. The infrastructure should also be organized to support identification, maintenance, and expansion without improvised interventions.

Optical Fiber and Uplinks

For backbones, the design should consider current capacity, growth, optical type, power budget, distance, redundancy, and expansion capability. An undersized backbone becomes a shared bottleneck for every service connected to it.

Power, UPS, and Protection

Power quality does not directly change throughput, but it affects operational stability of the equipment. Reboots, degraded power supplies, intermittent faults, or loss of distribution equipment may be perceived by users as network problems.

In critical environments, redundant power, UPS systems, surge protection, grounding, and supervision should be part of the infrastructure availability analysis.

Wi-Fi: Performance Depends on Airtime

In switched full-duplex Ethernet, each link has dedicated capacity according to its technology. In Wi-Fi, multiple clients share the radio medium. Therefore, the association rate displayed by a client does not represent throughput available to all users.

The design needs to consider coverage, SNR, interference, channel reuse, channel width, number of clients, airtime, retries, roaming, and application profiles.

A Slow Client Can Consume Airtime

A client operating with more robust modulation and a lower PHY rate may need more airtime to transmit the same amount of data. Wi-Fi performance should therefore be analyzed as utilization of a time-shared resource, not simply as “how many Mbps the AP supports.”

More Power Does Not Mean a Better Network

Increasing transmit power indiscriminately can increase cell overlap and co-channel interference. The design should balance AP and client behavior, cell geometry, and spectral reuse.

The wireless layer needs to be sized according to demand, not merely signal presence.

Segmentation, Broadcast, and Multicast

Segmentation using VLANs and subnets reduces broadcast domains, separates functions, and creates policy boundaries. However, creating excessive VLANs or doing so without an architecture also increases operational and routing complexity.

The article on Network Segmentation covers isolation criteria. From a performance perspective, the key point is to ensure that each domain has size, traffic, and paths consistent with its function.

Unnecessary broadcast traffic can consume host and link resources. Multicast, in turn, can be extremely efficient when properly designed, but it can cause flooding if mechanisms such as IGMP snooping and applicable multicast routing are not consistent with the topology.

Environments with video surveillance, AV over IP, device discovery, IoT, or automation need to map these flows explicitly.

Routing, Redundancy, and Convergence

Logical redundancy affects performance during normal conditions and, especially, during failures. The design of OSPF and BGP needs to consider not only reachability, but also policy, convergence, alternate paths, and residual capacity after a link failure.

A network may operate at 40% utilization on each of two paths and reach 80% or more when one fails. Therefore, capacity under degraded conditions must be analyzed before stating that the architecture is redundant.

The article on Addressing and Routing Structures in IP Networks examines summarization, gateways, ECMP, asymmetric routing, and design criteria in greater depth.

The Role of Hosts and Applications

Not every limitation is in the network. The host may limit performance because of CPU, memory, storage, drivers, NIC capabilities, interrupts, offload, buffers, or operating-system configuration.

At the application layer, short sessions, low concurrency, excessive polling, serialized operations, encryption, a slow database, or a saturated server can produce perceived “slowness” even when the network delivers low latency and no packet loss.

Tests should therefore separate at least three hypotheses:

1. the network path is limiting the transfer;
2. the host or server is limiting the transfer;
3. the application is limiting the perceived experience.

A synthetic network measurement between controlled endpoints helps separate these layers.

Synchronous Overload and Mass Events

Some events generate large-scale simultaneous demand. After power is restored, for example, hundreds of devices may reboot, request DHCP, resolve DNS, authenticate, synchronize time, download configuration, reconnect to servers, and start updates almost simultaneously.

Likewise, a scheduled task can start backups or updates on a large number of hosts in the same minute. This behavior produces a load very different from the daily average.

The design should consider concurrency, not only average consumption. Time distribution, caching, rate limiting, and task scheduling can reduce avoidable peaks.

Broadcast storms also belong to this category of amplified events. Mechanisms such as storm control, segmentation, and Layer 2 protection help limit the blast radius.

Baseline: Measure Before You Change

A baseline records how the network behaves under known conditions. Without a previous reference, it is difficult to determine whether a given latency, utilization level, or error volume is new or structural.

A useful baseline records different periods and conditions:

• peak and off-peak periods;
• business days and maintenance windows;
• traffic by link and class;
• RTT between representative points;
• loss and jitter;
• interface errors and drops;
• equipment CPU and memory;
• WAN and internet utilization;
• Wi-Fi behavior;
• major flows and applications.

A baseline is not a permanent snapshot. Changes in users, applications, cloud services, cameras, telephony, backups, and integrations alter demand and require the reference data to be updated.

Passive Measurement, Active Measurement, and Packet Capture

Observation methods answer different questions.

Method	Example	Advantage	Limitation
passive	SNMP, telemetry, logs	continuously observes production traffic	may have low temporal granularity
flow	NetFlow/IPFIX	identifies conversations and volume	does not show full packet content
active	ping, probes, synthetic tests	measures the path in a controlled manner	generates test traffic
throughput	iperf or equivalent method	measures practical capacity between endpoints	depends on hosts and test parameters
capture	packet capture	details sessions, retransmissions, and timing	requires the correct capture point and specialized analysis

The method should be selected according to the hypothesis being investigated. There is little value in capturing millions of packets without knowing which behavior needs to be demonstrated.

How to Structure a Throughput Test

A throughput test needs to record enough assumptions and parameters to be reproducible. A result without context has little engineering value.

The following should be defined:

• endpoints and interface capacities;
• physical and logical path;
• test direction;
• number of concurrent flows;
• transport protocol;
• duration;
• existing concurrent load;
• MTU and relevant parameters;
• host CPU and resources;
• metrics observed on intermediate equipment;
• acceptance criterion.

In TCP, RTT, window size, and loss strongly influence the result. In UDP, the offered rate, actual received rate, jitter, and loss need to be observed.

RFC 2544 is historically important for benchmarking internetworking devices, while RFC 6349 provides a framework focused on TCP throughput testing. The selected method should match the object of the test; a laboratory procedure should not be applied to a production network without adapting assumptions and risks.

Performance Under Normal and Failure Conditions

Accepting a network only under normal conditions can hide insufficient capacity. Redundant systems also need to be tested after controlled loss of elements provided for in the design.

Examples:

• loss of an aggregated uplink;
• failure of an LACP member;
• unavailability of a distribution switch;
• firewall failover;
• active-gateway change;
• loss of the primary WAN link;
• routing reconvergence;
• service transfer between nodes.

The requirement should state which service must continue, with what minimum capacity and what degradation is acceptable. “Having redundancy” is an architectural description, not a performance criterion.

High-Performance Network Architecture

Point adjustments can improve an existing network, but they cannot indefinitely compensate for an undersized architecture. Sustainable performance results from coordinated decisions involving capacity, topology, segmentation, routing, QoS, redundancy, and operations.

Size the Path, Not Only the Access Port

If users have 1 Gb/s ports, this does not mean each user needs 1 Gb/s simultaneously all the way to the internet. Nor does it mean a 1 Gb/s uplink is sufficient for dozens of ports merely because “nobody uses everything.”

Sizing should model aggregation and concurrency based on the actual traffic profile. Continuous video surveillance, storage, backup, voice, web browsing, and SaaS applications exhibit different behaviors.

Growth Capacity

Capacity reserve needs to consider growth and change scenarios. An architecture operating permanently near its limit has little margin for failures, new systems, or unexpected peaks.

The appropriate margin depends on criticality and ease of expansion, so it should be defined as a design decision rather than a universal percentage.

Technical Documentation and Performance

Documentation reduces diagnostic time because it turns the network into an understandable system. The Network Diagram should show paths and dependencies relevant to performance analysis.

Depending on the scale, the documentation package should include:

• physical and logical diagrams;
• nominal link capacities;
• uplink and aggregation matrix;
• VLANs, subnets, and gateways;
• routing policy;
• QoS classes and policies;
• redundancy and failover scenarios;
• asset and interface inventory;
• baseline and performance criteria;
• measurement points;
• test results and evidence;
• As-Built condition.

Without this foundation, an apparently simple change can move the bottleneck elsewhere or remove redundancy without the team realizing it.

Performance vs. Stability: How to Separate the Objectives

Performance asks whether the network delivers the required capacity and quality under defined conditions. Stability asks whether that behavior is maintained over time without failures, flaps, outages, or abnormal variations.

When the problem already exists and the objective is to identify the cause of slowness, loss, unstable Wi-Fi, a saturated uplink, or intermittent failure, the complementary content is Network Stability and Performance: Diagnosis, Causes, and Correction. Here, the focus remains on the engineering of metrics, capacity, and design criteria.

Common Errors in Performance Engineering

Error	Consequence
treating port speed as end-to-end performance	expectation incompatible with the actual path
observing only average utilization	microbursts and drops may remain invisible
measuring throughput without recording RTT, loss, and parameters	non-reproducible result
testing only normal conditions	insufficient capacity during a failure remains hidden
applying QoS without an end-to-end policy	markings and queues do not produce the expected behavior
ignoring pps and packet size	equipment may saturate before reaching its bit/s limit
treating Wi-Fi as wireless Ethernet	airtime, retries, and interference are left out of the design
blaming the network without isolating host and application	infrastructure replacement without resolving the cause
operating without a baseline	there is no reference for comparing degradation
accepting redundancy by visual inspection	failover may exist in the diagram and fail in production

Performance Acceptance Criteria

Acceptance criteria should be objective, measurable, and tied to applications. Instead of “high-performance network,” the design should define what will be measured, between which points, under what condition, and what result is acceptable.

An acceptance matrix can use the following structure:

Requirement	Method	Scenario	Evidence
throughput between critical points	controlled active test	normal load	test report and interface data
latency/RTT	synthetic probe	normal and peak	time series
jitter and loss	active test	sensitive flow	result by direction
uplink capacity	telemetry + load	expected peak	utilization, queues, and drops
QoS	concurrent traffic by class	contention	queues, markings, and loss by class
failover	controlled removal of an element	expected failure	time and application behavior
Wi-Fi	survey and capacity test	representative occupancy	coverage, retries, airtime, and throughput

Numerical values should not be copied from a generic table. They should derive from the requirements of voice, video, control, corporate systems, storage, cloud, and other services actually in use.

Commissioning and Performance Evidence

Commissioning turns requirements into evidence that the delivered installation works according to the design. In network environments, this involves more than pinging gateways.

The plan may combine:

• physical-layer certification;
• verification of topology and configurations;
• throughput tests;
• measurement of delay, jitter, and loss;
• QoS validation;
• multicast testing where applicable;
• failover and convergence;
• operation under degraded conditions;
• verification of monitoring and alarms;
• recording of the delivery baseline;
• As-Built update.

The network should transition from design to operations with criteria, documentation, and metrics that allow future performance to be compared with the accepted condition.

Final Considerations

Network performance is not synonymous with a fast link. It is the measurable result of the interaction among capacity, queues, protocols, physical and logical architecture, hosts, and applications.

Sound engineering starts with service requirements, converts those requirements into expected capacity and behavior, measures the path using reproducible methods, and tests normal and degraded scenarios. Throughput, latency, jitter, and loss stop being isolated numbers and become decision and acceptance criteria.

When baseline, observability, design, and commissioning remain connected, the organization can distinguish legitimate demand growth, structural bottlenecks, configuration failures, and limitations in the application itself — and can plan expansion before user experience deteriorates.

Technical References

[1] IETF. RFC 2544 — Benchmarking Methodology for Network Interconnect Devices. Available at: [https://www.rfc-editor.org/rfc/rfc2544](https://www.rfc-editor.org/rfc/rfc2544).

[2] IETF. RFC 2681 — A Round-trip Delay Metric for IPPM. Available at: [https://www.rfc-editor.org/rfc/rfc2681](https://www.rfc-editor.org/rfc/rfc2681).

[3] IETF. RFC 3393 — IP Packet Delay Variation Metric for IP Performance Metrics (IPPM). Available at: [https://www.rfc-editor.org/rfc/rfc3393](https://www.rfc-editor.org/rfc/rfc3393).

[4] IETF. RFC 6349 — Framework for TCP Throughput Testing. Available at: [https://www.rfc-editor.org/rfc/rfc6349](https://www.rfc-editor.org/rfc/rfc6349).

[5] IETF. RFC 9293 — Transmission Control Protocol (TCP). Available at: [https://www.rfc-editor.org/rfc/rfc9293](https://www.rfc-editor.org/rfc/rfc9293).

[6] IETF. RFC 2474 — Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers. Available at: [https://www.rfc-editor.org/rfc/rfc2474](https://www.rfc-editor.org/rfc/rfc2474).

[7] IETF. RFC 3246 — An Expedited Forwarding PHB (Per-Hop Behavior). Available at: [https://www.rfc-editor.org/rfc/rfc3246](https://www.rfc-editor.org/rfc/rfc3246).

[8] ITU-T. Y.1540 — Internet protocol data communication service — IP packet transfer and availability performance parameters. Available at: [https://www.itu.int/rec/T-REC-Y.1540/en](https://www.itu.int/rec/T-REC-Y.1540/en).

[9] ITU-T. Y.1541 — Network performance objectives for IP-based services. Available at: [https://www.itu.int/rec/T-REC-Y.1541/en](https://www.itu.int/rec/T-REC-Y.1541/en).

Frequently Asked Questions

What is the difference between bandwidth and throughput?

Bandwidth, or nominal capacity, represents the technological limit of the link. Throughput is the rate actually transferred along the path and may be lower because of overhead, contention, loss, retransmission, host limitations, or intermediate processing.

What is the difference between throughput and goodput?

Throughput accounts for the volume actually transported. Goodput considers only useful data delivered to the application, excluding retransmissions and overhead that do not constitute useful content.

Is jitter the same as latency?

No. Latency measures delay; jitter measures variation in that delay over time. A network can have acceptable average latency and still impair real-time applications if variation is high.

Can a network with low average utilization still be congested?

Yes. Microbursts can saturate an interface for very short periods and cause queues or drops without appearing in multi-minute aggregate averages.

Does QoS increase bandwidth?

No. QoS organizes how available capacity is distributed during contention. It can protect sensitive traffic, but it does not create additional bandwidth.

Why can TCP throughput decrease on long-distance links?

RTT, loss, transport window, and congestion-control mechanisms affect the rate. On high bandwidth-delay-product paths, a single session may not fill the link if windows and transport behavior are not appropriate.

How should network performance be tested correctly?

Define endpoints, path, direction, protocol, duration, concurrent load, test parameters, and acceptance criteria. Correlate throughput with latency, loss, queues, host resources, and metrics from intermediate equipment.

Are network performance and network stability the same thing?

No. Performance evaluates capacity and quality under defined conditions. Stability evaluates whether that behavior is maintained over time without failures, flaps, or abnormal variations.

Complementary Technical Materials

Related Services

• Logical Network and Corporate Networks Design
• Engineering Technical Due Diligence
• Engineering Tests and Technical Testing
• Engineering Commissioning

Main Content on the Topic

• Network Traffic: flows, load, broadcast, multicast, and capacity
• Network Monitoring: metrics, availability, performance, and observability
• NetFlow: what it is, how it works, and how to analyze network traffic
• Network Management: FCAPS, SNMP, configuration, performance, and security
• Network Stability and Performance: diagnosis, causes, and correction

Related Technical Content

• Logical Network: VLANs, IP, routing, segmentation, and design
• Network Segmentation: fundamentals, models, best practices, and when to use it
• Addressing and Routing Structures in IP Networks
• Network Diagram: types, logical and physical architecture, and technical documentation
• Complete Guide to Network Architecture
• NetBox as the Source of Truth for Infrastructure, Networks, IPAM, DCIM, and Automation