update book for typos
update branch to fit with main
This commit is contained in:
@@ -11,13 +11,14 @@ sidebar_position: 2
|
||||
|
||||
Most cloud & internet stacks can be compared to an onion, where each layer represents an additional component or service added to address a problem in the system. However, like peeling an onion, as you dig deeper, you often find that these layers are not solving the core issues but merely masking symptoms, leading to a complex and often fragile structure.
|
||||
|
||||
**Quick Fixes and Additions**
|
||||
## Quick Fixes and Additions
|
||||
|
||||
- **Problem:** When an issue arises, such as performance bottlenecks or security vulnerabilities, organizations often add another tool, service, or layer to the cloud stack to mitigate the issue.
|
||||
- **Analogy:** This is akin to applying a bandage or taking a painkiller when you feel pain. The immediate discomfort might be alleviated, but the underlying problem remains untouched.
|
||||
|
||||
## Painkiller Approach: Treating Symptoms, Not Causes
|
||||
|
||||
### Painkiller Approach: Treating Symptoms, Not Causes
|
||||
This onion-like structure represents a "painkiller approach" to cloud management, where immediate issues are addressed with quick fixes rather than tackling the underlying problems. Over time, this approach leads to several challenges.
|
||||
|
||||
This onion-like structure represents a "painkiller approach" to cloud management, where immediate issues are addressed with quick fixes rather than tackling the underlying problems.
|
||||
|
||||
|
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: 'Hardware Is Powerfull'
|
||||
title: 'Hardware Is Powerful'
|
||||
sidebar_position: 6
|
||||
hide_title: true
|
||||
---
|
||||
|
||||
# Hardware Is Powefull
|
||||
# Hardware Is Poweful
|
||||
|
||||

|
||||
|
||||
@@ -20,15 +20,13 @@ This highlights a regression in our ability to fully utilize computer hardware.
|
||||
|
||||
We are committed to bridging this gap by optimizing our approach to hardware utilization, thereby unlocking its full potential.
|
||||
|
||||
## Why are servers so badly used?
|
||||
## Why Are Servers So Badly Used?
|
||||
|
||||

|
||||
|
||||
Context switches occur when a computer's processor shifts from executing one task (or context) to another. While necessary for multitasking, too many context switches lead to inefficiency, as demonstrated in this diagram. Here's a simplified explanation:
|
||||
Context switches occur when a computer's processor shifts from executing one task (or context) to another. While necessary for multitasking, too many context switches lead to inefficiency, as demonstrated in this diagram. Below, we provide a simplified explanation.
|
||||
|
||||
---
|
||||
|
||||
## Why Context Switches Are a Problem:
|
||||
## Why Context Switches Are a Problem
|
||||
|
||||
### What Are Context Switches?
|
||||
|
||||
@@ -54,31 +52,30 @@ Each switch requires saving and loading the state of a process. This takes time
|
||||
- Instead of performing tasks like running applications or processing data, the computer is stuck managing unnecessary complexity.
|
||||
|
||||
|
||||
### Simplified Analogy:
|
||||
## Simplified Analogy
|
||||
|
||||
Imagine driving on a highway where you have to stop and pay a toll at every intersection. You waste more time paying tolls than actually driving to your destination. Similarly, excessive context switches in modern systems cause the computer to "stop and pay tolls" constantly, leaving little time for real work.
|
||||
|
||||
|
||||
### How did we get here:
|
||||
## How Did We Get Here
|
||||
|
||||

|
||||
|
||||
|
||||
## How do we resolve this problem.
|
||||
## How to Resolve This Problem
|
||||
|
||||
We decided to reinvent the way an operating system functions in a cloud and data center context.
|
||||
While leveraging the Linux kernel, we rebuilt many surrounding tools to minimize complexity and reduce context switching.
|
||||
This approach results in significantly improved security, scalability, and sustainability.
|
||||
|
||||
> [see here for more information about our operating system called Zero-OS](../key_innovations_overview/compute/zos_compute.md)
|
||||
|
||||
--------
|
||||
--------
|
||||
> [See here for more information about our operating system called Zero-OS](../key_innovations_overview/compute/zos_compute.md)
|
||||
|
||||
### Context Switching Details
|
||||
|
||||
In the context of CPU scheduling in Linux (and in most modern operating systems), a context switch refers to the process of saving the state of a currently running process (such as its registers, program counter, and other relevant information) and loading the state of a different process to allow it to run. This switching of execution from one process to another is a fundamental aspect of multitasking operating systems, where multiple processes share the CPU's time.
|
||||
|
||||
### How It Works
|
||||
|
||||
Here's how a context switch typically works in Linux:
|
||||
|
||||
1. **Interrupt Handling**: When a higher-priority process needs to run or an event requiring immediate attention occurs (such as I/O completion), the CPU interrupts the currently running process.
|
||||
@@ -91,6 +88,8 @@ Here's how a context switch typically works in Linux:
|
||||
|
||||
5. **Execution**: The newly loaded process begins executing on the CPU.
|
||||
|
||||
### Overhead and Performance Impact
|
||||
|
||||
Context switches are essential for multitasking, but they come with overhead that can impact system performance:
|
||||
|
||||
1. **Time Overhead**: Context switches require time to save and restore process states, as well as to perform scheduling decisions. This overhead adds up, especially in systems with many processes frequently switching contexts.
|
||||
|
@@ -20,7 +20,7 @@ Security is another area where TCP/IP falls short. It wasn’t designed with cyb
|
||||
|
||||
Modern services and devices have also outgrown the static design of TCP/IP. The system assumes that servers and devices stay in fixed locations, but today’s internet is dynamic. Cloud services, mobile devices, and apps often move across networks. This static model creates inefficiencies and slows down the system.
|
||||
|
||||
Adding to the problem is the internet’s dependence on a few centralized services, such as Google, Amazon, and Microsoft. These companies control much of the infrastructure we rely on for communication, storage, and services. If one of them fails—or if access is blocked due to political conflicts—entire regions could lose critical internet functions. This centralization makes the system fragile and leaves users vulnerable.
|
||||
Adding to the problem is the internet’s dependence on a few centralized services, such as Google, Amazon, and Microsoft. These companies control much of the infrastructure we rely on for communication, storage, and services. If one of them fails—or if access is blocked due to political conflicts—entire regions can lose critical internet functions. This centralization makes the system fragile and leaves users vulnerable.
|
||||
|
||||
> The stakes are high. The internet is essential for communication, education, business, and so much more. Yet its foundation is crumbling under modern demands. Without major changes, we’ll see more frequent failures, slower services, and increased vulnerabilities. In extreme cases, parts of the internet could break entirely.
|
||||
|
||||
@@ -29,15 +29,16 @@ To fix this, we need a smarter, more resilient approach. Decentralized networks
|
||||
> The bottom line is clear: the internet’s outdated foundation is holding us back. If we want the internet to remain reliable and serve future generations, we must address these issues now. A decentralized, secure, and modernized internet isn’t just a technical upgrade—it’s a necessity for our connected world.
|
||||
|
||||
|
||||
## Tech brief (only for the experts)
|
||||
## Tech Brief
|
||||
|
||||
The following tech brief is aimed at experts.
|
||||
|
||||
### 1. **Lack of Session Management**
|
||||
- **TCP/IP’s Shortcomings:**
|
||||
- **TCP/IP’s Shortcomings**
|
||||
- TCP/IP lacks true session management. A session represents an ongoing communication between two entities (e.g., a user browsing a website). If the connection is interrupted (e.g., due to a network outage or device change), the session is lost, and applications must restart or recover manually.
|
||||
- This flaw creates inefficiencies in modern applications that require reliable, continuous communication, such as video calls, gaming, or IoT devices.
|
||||
|
||||
- **Why It Matters:**
|
||||
- **Why It Matters**
|
||||
- Every time a session breaks, applications have to rebuild connections at a higher level (e.g., re-authenticate or restart a video call). This is inefficient and increases complexity, making the internet fragile and less resilient.
|
||||
|
||||
|
||||
@@ -45,58 +46,58 @@ To fix this, we need a smarter, more resilient approach. Decentralized networks
|
||||
|
||||
### 2. **Layer Violations**
|
||||
|
||||
- **The Problem:**
|
||||
- **The Problem**
|
||||
- TCP/IP combines different functionalities into a single stack, leading to inefficiencies. For example:
|
||||
- Routing decisions happen at the IP layer.
|
||||
- Reliable data transfer happens at the TCP layer.
|
||||
- However, these layers are not isolated and often interfere with each other, creating unnecessary overhead.
|
||||
|
||||
- **Impact:**
|
||||
- **Impact**
|
||||
- Modern networks require additional layers (e.g., firewalls, VPNs, NATs) to patch these issues, making the architecture increasingly complex and brittle.
|
||||
|
||||
---
|
||||
|
||||
### 3. **No Built-In Security**
|
||||
- **TCP/IP Design Flaw:**
|
||||
- **TCP/IP Design Flaw**
|
||||
- Security was not a priority when TCP/IP was designed. The protocols do not inherently protect against common threats like spoofing, hijacking, or denial of service.
|
||||
- IPv6 introduces some improvements, such as built-in IPsec, but these are optional and often not used, leaving the same vulnerabilities.
|
||||
|
||||
- **Impact:**
|
||||
- **Impact**
|
||||
- Every modern application must implement its own security mechanisms (e.g., HTTPS, VPNs), leading to duplicated efforts and inconsistent protections.
|
||||
|
||||
---
|
||||
|
||||
### 4. **Scalability Issues**
|
||||
|
||||
- **IPv4 vs. IPv6:**
|
||||
- **IPv4 vs. IPv6**
|
||||
- IPv4, with its 32-bit addressing, exhausted available addresses, leading to NAT (Network Address Translation) as a workaround. This introduced complexity and broke the end-to-end connectivity principle of the internet.
|
||||
- IPv6, with 128-bit addressing, solves the address exhaustion problem but does not address underlying issues like routing table explosion or inefficiencies in the protocol stack.
|
||||
|
||||
- **Routing Problems:**
|
||||
- **Routing Problems**
|
||||
- The lack of built-in session and naming management makes routing inefficient. Large routing tables and decentralized updates slow down the internet and make it harder to scale.
|
||||
|
||||
---
|
||||
|
||||
### 5. **No Support for Application-Centric Networking**
|
||||
- **TCP/IP’s Assumption:**
|
||||
- **TCP/IP’s Assumption**
|
||||
- The protocol assumes communication happens between fixed endpoints (e.g., IP addresses). Modern applications, however, focus on data and services rather than specific endpoints. For example:
|
||||
- Cloud applications may move across data centers.
|
||||
- Mobile devices frequently change networks.
|
||||
- TCP/IP’s static model is incompatible with this dynamic, service-oriented world.
|
||||
|
||||
- **Impact:**
|
||||
- **Impact**
|
||||
- Workarounds like DNS (Domain Name System) and CDNs (Content Delivery Networks) add layers of complexity, but they’re still built on a flawed foundation.
|
||||
|
||||
---
|
||||
|
||||
### RINA: A Better Alternative
|
||||
|
||||
The **Recursive Inter-Network Architecture (RINA)** proposes a solution to the flaws of TCP/IP by rethinking the internet's architecture. Here’s how RINA addresses these issues:
|
||||
The **Recursive Inter-Network Architecture (RINA)** proposes a solution to the flaws of TCP/IP by rethinking the internet's architecture. Here’s how RINA addresses these issues[^1]:
|
||||
|
||||
1. **Unified Layering:**
|
||||
1. **Unified Layering**
|
||||
- Unlike TCP/IP, which has rigid and distinct layers, RINA uses recursive layers. Each layer provides the same functionalities (e.g., routing, security, session management), simplifying the architecture.
|
||||
|
||||
2. **Built-In Session Management:**
|
||||
2. **Built-In Session Management**
|
||||
- RINA natively supports session management, ensuring continuity and reliability for modern applications, even in the face of interruptions.
|
||||
|
||||
3. **Application-Centric Networking:**
|
||||
@@ -108,11 +109,4 @@ The **Recursive Inter-Network Architecture (RINA)** proposes a solution to the f
|
||||
5. **Simplified Routing and Scaling:**
|
||||
- RINA reduces the size and complexity of routing tables, making the network easier to scale and manage.
|
||||
|
||||
- **Source:**
|
||||
- [RINA Leaflet](https://www.open-root.eu/IMG/pdf/rina-leaflet_20191115_en.pdf)
|
||||
|
||||
---
|
||||
|
||||
### More info
|
||||
|
||||
more info [https://www.open-root.eu/IMG/pdf/rina-leaflet_20191115_en.pdf](https://www.open-root.eu/IMG/pdf/rina-leaflet_20191115_en.pdf)
|
||||
[^1]: [RINA Leaflet](https://www.open-root.eu/IMG/pdf/rina-leaflet_20191115_en.pdf)
|
Reference in New Issue
Block a user