Return to Answer

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.

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...

Without further context, that textbook might just be talking about circuit-switched networks (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.

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.

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.

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

In packet-switched networks, unless the layers below the transport layer provide some kind of basis for that timing guarantee (see QoS), there's no way an L4 protocol can generate that kind of guarantee out of thin air. It is utterly impossible over a network that you don't control rather tightly.

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

You can generate 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/link loads change significantly. That's why TCP recalculates them all the time.

Without further context, that textbook might just be talking about circuit-switched networks (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.

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.