how a transport-layer protocol can provide timing guarantees?

Question

I'm reading a textbook which says:

A transport-layer protocol can also provide timing guarantees. As with throughput guarantees, timing guarantees can come in many shapes and forms. An example guarantee might be that every bit that the sender pumps into the socket arrives at the receiver’s socket no more than 100 msec later.

I'm a little bit confused, because we know that queuing delays is not fixed and depend on the traffic of a router, then how can transport-layer protocol provide timing guarantees service while it can be affected by other factor such as busy traffic which affects queueing delay?

Answer 1

Most communication networks are designed to be centrally controlled and scheduled. CAN, OTN, SDH, FR, GSM etc.

In the cell phone network central clocks are distributed (via network typically) to every network element. All traffic is time switched on/off the network. This allows the network wide latency to be fixed and predictable.

The alternative is Ethernet/Wifi where there is no central scheduling. In this model everyone waits for the medium to go quiet then transmits. In this situation packets can collide (two stations talking at the same time). In ethernet there is Collision Detection and in Wifi there is Collision Avoidance.

On centrally scheduled networks ATM QOS comes in 5 variants.

• Constant Bit Rate (CBR) CBR is like having a dedicated line and you get 100% of the bandwidth

• Variable Bit Rate (VBR) VBR you are guaranteed a rate then you can get more https://www.cisco.com/c/en/us/support/docs/asynchronous-transfer-mode-atm/atm-traffic-management/6194-atm-vbrshape.html

• Available Bit Rate (ABR). ABR is whatever is left over (no guarantee)

The two other variants are Real Time and Non Real Time. That's how frequently the use is calculated.

QOS in Ethernet is typically implemented as WRED - Weighted Random Early Detection and Discard https://en.wikipedia.org/wiki/Weighted_random_early_detection Packets are put into 3 or more queues. The highest priority queue is drained first then other ques in order of priority. If any queue looks like it's going to overflow packets are dropped early to prevent overrun.

To answer your specific question: The things that cause variability in latency are: QOS queuing, CSMA/CD and retransmission, Router load (as the router gets more load it will slow down at 75% of capacity), Packet size (lots of small packets reduces overall bandwidth), Overhead signaling (Wifi management frames), Overall router load (some events on routers control plane can affect latency). L1/L2 activity (ARP), Fragmentation (if the router needs to fragment you will get a significant performance hit), Re-assembly, Re-ordering packets (specifically bad with IPSec) and probably more that I have forgotten.

Answer 2

Without further context, that textbook might just be talking about circuit-switched networks like ATM or SDH (where delay and bandwidth guarantees come pretty much naturally) or it is hypothesizing.

In packet-switched networks, there's no way a transport-layer protocol can generate a timing guarantee out of thin air without the layers below providing some kind of basis for that (see qos). It is utterly impossible over a network that you don't control rather tightly. I searched for the text you quoted and it is repeated in many forms all over the Internet. Yet, it is completely wrong outside a QoS context.

Likewise, a bandwidth guarantee isn't anything you can generate "on top" either.

You can calculate good estimates for bandwidth and delay - that is in fact what TCP does under the hood - but these estimates are temporary in nature and can change at any time, especially when the network loads change and there's congestion somewhere in the path. That's why TCP recalculates the path's round-trip time all the time and adapts its data flow to it.

PS: I could locate your quoted text at https://electronicspost.com/transport-services-available-to-applications/ which is specifically referring to TCP - apparently, that poster is not a network engineer and might not know exactly what he was talking about...