network architecture

2020-08-29

This post is a draft. What is a draft?

Networks are organized in stacks of layers. Each layer is built on top of the previous (below) one. The purpose of a layer is to offer services to the next (upper) one, and simultaneously, to shield the complexity of the previous (lower) layers. You know this concept in object-oriented programming: encapsulation. Indeed, layers are often imagined as hardware devices. While hardware is involved in layers, especially in the lowest layers (or below the stack), layers are made of software most of the time.

Besides offering services to layers on the same stack, each layer n can communicate with a corresponding peer layer n in another stack, on another host. This is possible because both layers deal with the same languages and data granularity. The layers are said to follow a layer n protocol.

A protocol is an agreement between communicating parties on how communication is to proceed.

As shown in the picture, layers that are at the same level, i.e., peers, communicate with each other. In reality, communication does not happen between layers. Communication does not happen between stacks, either! Communication is nothing else than signals exchanged by a physical medium (e.g., a cable). Information is passed to layers below the one that wishes to reach its peer. This is done through interfaces.

An interface defines those services and primitive operations that a lower layer makes available to an upper layer. The principle that guides designing these interfaces is simplicity. The reason for the sought simplicity is that it gets easier to replace layers in a stack. As long as the devices provide the same primitives as before, layers above and below the swapped one will not even notice a difference. Despite the apparent complexity of stacks, layers, peers, virtual communication among peers that does not happen physically, and physical mediums, it all boils down to primitive functionalities provided by interfaces. Implementation protocols among peers does not have to be the same—in fact, it is not most of the time—because the interfaces behave the same and follow the same rules.

A set of layers and protocols is called a network architecture. An architecture specification is a set of rules and characteristics, but not a set of implementation details, which are free for the implementer to be performed. A list of the protocols used by a certain system, one protocol per layer, is called a protocol stack.

How does communication work, then? Imagine this analogy.

A local CEO, from a small family-owned business, speaks only German.

She has a good business opportunity that she wants to propose to a French CEO, who however speaks French only. A direct contact between the two CEOs would not make sense, as they would not understand each other.

Both CEOs have a secretary.

The French secretary speaks French and English. He can communicate with the French CEO.

The German secretary speaks German and English. She can communicate with the German CEO.

The two secretaries can communicate with each other because both speak English.

Now the German CEO can communicate with the French CEO. She drafts a proposal, in German, and passes it to her secretary.

The secretary does not understand the content of the proposal fully, it is not his duty. What he can do is to translate the proposal into English and add a deadline for the French company to respond.

He sends it to the French secretary, per e-mail. The French secretary writes a translation, from English to French, of the proposal. She does not understand the proposal very well, but she can translate it.

The French CEO reads the translated proposal, accepts the proposal, and tells the secretary to contact the German company immediately.

The French secretary decides to call the German secretary. The secretaries converse in English, of course.

The German secretary happily conveys the good news to the German CEO, in German. All is well. Celebration endues.

The two respective CEOs and secretaries are layers of two network stacks.

The two CEOs are peers who communicate with each other, as they comprehend the proposal once it gets delivered in a language that they can understand. They do not communicate with each other directly, though. The two secretaries are peers of the same level, the one at the lowest level. They can communicate with their CEOs through their interfaces (German and French, respectively) and use the interface below them to deliver the communication through different media (E-mail in the inquiry, phone call in the response).

The two CEOs do not know, and do not care, about three things:

  1. The proposal contents (when not in their native language).
  2. The details that were added in between (deadlines).
  3. How the secretaries communicated with (E-mail first, phone then).

Layers add information to each message, which is ignored by layers not at their level. Often, this information is conveyed in headers, which get appended or prepended to messages.

Design issues with networks

You may have started noticing that networks are made of so many parts, and so many things might go wrong. There are several mechanisms in place to make network communication as reliable as possible, some of which are at the cost of performance. So many things can go wrong, the simplest of which is a signal issue that might make a bit flip its value (from 0 to 1) before it reaches its destination. Another one could be weak radio signals, another a software bug in a network stack, and so on.

Error detection codes is one of such mechanisms to help to find and to recover reliability issues. The most basic operation is to allow information to be transmitted again, up to when it is correct. A code would simply mark some information as unreadable. More powerful and better organized codes allow for error correction at the destination. This is often achieved by transmitting redundant information by following certain strategies so that it is not 1-to-1 copies that are transmitted around. Otherwise, information would be 2x, 3x, 4x bigger than needed!

Another issue lies in finding a good path through a network and between networks. Thinking of roads in a city as analogy, you might take very different paths to go from point A to point B. Some of these roads might be broken, other might have so much traffic that you do not arrive on time, and so on. But perhaps there is a path that is neither broken nor congested. Data packets, however, do not know which route to take, let alone the best one. The network should make this decision. This is called routing.

Since there are many devices on the network, some of which receive packets that are not for them, and are either ignored or forwarded (according to the transmission method), every layer needs a way for identifying the senders and receivers. This is called addressing.

Another aspect is that sometimes there is a maximum size for a message that a network can transmit. Sometimes this is imposed, sometimes this is due to the medium for transmission, sometimes due to hardware limitations. Such a limit requires mechanisms for disassembling and reassembling messages. This is called internetworking.

Issues might arise when a sender is too fast for the receiver. Too many packets of a too big size overall are sent. The receiver cannot keep up with it. The receiver can provide feedback to the sender to slow down. This is called flow control. When this problem gets generalized because too many hosts send too much traffic, a network congestion happens. A light strategy to overcome congestion is also for senders to lower their expectations in terms of performance.

Sometimes, there is a need to deliver an X amount of data by a certain amount of time, or with the lowest reaction times as possible. This is the case, for example, with audio and video streaming. Rather than experiencing the annoying Netflix red loading circle of death, you might prefer a couple of seconds where video looks lightly pixelated. QoS - Quality of Service is a set of mechanisms that allow a higher confidence (not insurance) that certain requirements for traffic are met

The last major design issue is on security. We do not want unauthorized devices to intercept, let alone read, traffic content that was not for them to receive. There are several aspects on network security, ranging from authentication, encryption of the transmitted data, mechanisms to ensure that all points in a path are who they tell they are, and mechanisms to ensure that the transmitted data was not changed while in movement. These mechanisms are present in several layers of a stack.

Connection-oriented vs. Connectionless services

Layers offer services to layers above them. These services are not protocols. A protocol, defined in a generic way before, is a set of rules and formats (not their implementation!) offered by layers to their peers. A service is a set of primitives (simple operations such as connect(), accept(), and receive()) that a layer offers to the one above it.

Here is a picture that shows the difference between a service and a protocol.

Those who implement protocols do it with services, as a direct line of communication between peers does not exist. The beauty of such encapsulation mechanism is that protocols can evolve and be swapped entirely as long as who implements them does it by following service rules. Protocols change, services tend to never change.

Two types of services are offered by layers: connection-oriented and connectionless.

Connection-oriented service is modeled after a phone call. The service user establishes a connection, uses the connection, and releases the connection. Information (bits) is pushed from the sender to the receiver, who must simply listen for it. Once you establish a phone call, you do not have to dial the phone number before every sentence that you speak. The connection is already established. Packets do not typically contain a destination address because this issue is dealt by the sender already. Order of communication bits is usually preserved.

Services can be categorized according to their reliability. Reliable services never lose data. Unless you physically interrupt transfer lines or takeout routers, of course. Achieving reliability requires acknowledgment mechanisms (which are in the form of S: “I am sending you data” R: “Received” R: “I am waiting for data” S: “Received” S: “I sent data” R: “Received”). This back-and-forth acknowledgment system introduces delays that are unacceptable in certain contexts. This is why we use unreliable services, too. These services provide no guarantee of deliverability. There are no mechanisms to acknowledge receipt of messages. But on the other hand, these services are very fast.

Connection-oriented services can be further divided into:

Connectionless service is modeled after the postal system. Every message that is sent contains the destination address, as with a letter in an envelope. Messages travel networks and are routed through intermediate nodes independent of each other. It might even happen that they do not even take same path. Order of communication bits is not preserved by the service, so someone else will have to deal with this.

There are (un)reliability aspects in connectionless services, too. Unreliable connectionless service is often called datagram service, which also lacks acknowledgments. It works as with a telegram. Communication happens and it is maybe received at an end. There is no way to know whether it was received. Sometimes, reliability in absence of connection is desired. An acknowledged datagram service can be provided for these applications. This works as with sending a registered letter and requesting a return receipt. When the receipt comes back, the sender knows that the message was received. A different service is the request-reply one. In this mode, the sender transmits a single request in a datagram. The reply to it contains the answer.

Connectionless services can be thus further divided into:

I do not use a commenting system anymore, but I would be glad to read your feedback. Feel free to contact me.