Connection oriented or Connectionless? Why not both?

Connection oriented vs. connectionless has always been a hot debate in the networking community. Both approaches have its pros and its cons, so it seems natural that there will be situations were using connections make more sense and some others were using a connectionless approach is more efficient.

For example, as traffic becomes denser (closer to the network core) connections become more effective; when traffic is more stochastic (closer to the access networks) connectionless is more effective. Therefore, why should this be a debate at all? We should try to find a model that accomodates both connection and connectionless, and even more, that saw pure connections and pure connectionless as the extremes of a continuous function. But, how we can do this?

The first part is having a service interface that abstracts both options, so that a user of the network can request both approaches trough the same interface. But, wait a second… Should the user of the network care about this detail? Distributed applications use the network to communicate, they need communication resources to be allocated to them, with certain characteristics (bandwidth, latency, jitter, reliability, …), commonly known as Quality of Service.  If the network uses a connection or connectionless approach, the application doesn’t matter, as long as its demands are met. Therefore, a good API for a network service could be the following one:

  • port_id allocate(destinationApplicationName, QualityOfServiceParameters)
  • send(port_id, buffer_of_bytes)
  • read(port_id, buffer_of_bytes)
  • deallocate(port_id)

The allocate primitive allocates communication resources for the requesting application to communicate to the destination application. These communication resources must meet the quality standards defined by the QoS parameters requested by the application. An identifier for the allocated resources (port_id) is returned to the requesting application, who can use it to read an write bytes. The deallocate primitive frees all the resources previously allocated. By using this API, the decision of using connections or connectionless mechanisms to accomodate the application requests is a decision of the network, and depends on the traffic characteristics and the QoS requested.

Having defined the interface, now we need to find an implementation that can see connections and pure connectionless operation as extremes of a continuous function. But what can be this function? Let’s try to think deeper into the nature of connections and datagrams.

Connections try to minimize the amount of routing state in the network. Although this may not look intuitive, let’s see what happens when a connection fails. If a node in the connection path breaks, the rest of the nodes participating in the virtual circuit don’t have enough information on what to do, and therefore cannot take an action to repair the problem. On the contrary, in a pure connection-less network all the nodes know how to route all the packets (the packets contain enough information for the nodes to take routing decisions), therefore the network can react on node or interface failures.

We can see connections as minimal distributed state and datagrams as maximal distributed state. Another way of looking at it is that with connection-oriented resource allocation, information (including routing) is only stored with nodes on the path of the connection; whereas with connectionless resource allocation, information is stored with every node. Let’s consider this to be the function we were looking for? The probability that this PDU is processed precisely like the last PDU in this flow varies between 0 and 1.

Figure 1. Connection oriented behaviour

Figure 2. Pure conncetionless beahaviour

Figure 3. Hybrid behaviour

Based on information from other routers, each router computes the probability it will be on the path for this flow and if so what resources should it “allocate.”  This leads to a model where flows are spread across different paths and resources are allocated on the basis of the probability of their use. For example (figures 1,2,3) if we assume that there are m paths between A and B, a connection is represented by one path having the probability 1 of being used (figure 1). For example, there might be 4 paths between two points with probabilities: .2, .4, .4, and 0 (figure 3). Pure connectionless is  represented by each path being equally likely or 1/n (figure 2). Distributions may be anything in between. The question is what resources should be allocated for these probabilities given the desired QoS. Routers allocate resources based on the probability that they will receive PDUs for a flow. This allows routers to reserve resources to better respond to failures during the transients while resource-allocation information is updated in response to a failure.

A lot of information in very little space, but for a complete discussion on the topic you can take a look at chapter 3 of John Day’sPatterns in Network Architecture: A return to fundamentals“.

This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.