Transport Services Provided by the Internet

Transport Services Provided by the Internet

Up until this point, we have been studying transport services that a computer network could provide generally. Let's now get more particular and look at the type of application support provided by the Internet. The Internet (and, more usually, TCP/IP networks) makes two  transport protocols available to applications, UDP and TCP. When you (as an application developer) create a new network application for the Internet, one of the first decisions you have to make is whether to use UDP or TCP. Each of these protocols offers a different set of services to the invoking applications. Figure 1 shows the service requirements for some selected applications.

TCP Services

The TCP service model contains a connection-oriented service and a reliable data transfer service. When an application invokes TCP as its transport protocol, the application receives both of these services from TCP.

●  Connection-oriented service. TCP has the client and server exchange transport-layer control information with each other before the application-level messages begin to flow. This so-called handshaking procedure alerts the client and server, allowing them to prepare for an onslaught of packets. After the handshaking phase,

Requirements of selected network applications

a TCP connection is said to exist between the sockets of the two processes. The connection is a full-duplex connection in that the two processes can send messages to each other over the connection at the same time. When the application finishes sending messages, it must remove the connection. The service is referred to as a "connection-oriented" service rather than a "connection" service because the two processes are connected in a very loose manner. In "Transport Layer" well discuss connection-oriented service in detail and study how it is implemented.

●  Reliable data transfer service. The communicating processes can rely on TCP to deliver all data sent without error and in the proper order. When one side of the application passes a stream of bytes into a socket, it can count on TCP to deliver the same stream of bytes to the receiving socket, with no missing or duplicate bytes.

TCP also contains a congestion-control mechanism, a service for the common welfare of the Internet rather than for the direct benefit of the communicating processes. The TCP congestion-control mechanism throttles a sending process (client or server) when the network is congested between sender and receiver. As we will see in "Transport Layer". TCP congestion control also attempts to limit each TCP connection to its fair share of network bandwidth. The throttling of the transmission rate can have a very adverse effect on real-time audio and video applications that have minimum throughput requirements. Moreover, real-time applications are loss-tolerant and do not need a fully reliable transport service. For these reasons, developers of real-time applications sometimes decide to run their applications over UDP rather than TCP.

UDP Services

UDP is a no-frills, lightweight transport protocol, providing minimum services. UDP is connectionless, so there is no handshaking before the two processes start to

communicate. UDP provides an untrustworthy data transfer service - that is, when a process sends a message into a UDP socket, UDP provides no guarantee that the message will ever reach the receiving process. Moreover, messages that do arrive at the receiving process may arrive out of order.

UDP does not contain a congestion-control mechanism, so the sending side of UDP can pump data into the layer below (the network layer) at any rate it pleases. (Note, however, that the actual end-to-end throughput may be less than this rate due to the limited bandwidth of intervening links or due to congestion). Because real-time applications can often tolerate some loss but require a lowest rate to be effective, developers of real-time applications sometimes choose to run their applications over UDP, thus circumventing TCP's congestion-control mechanism and packet overheads. However, because many firewalls are configured to block (most types of) UDP traffic, designers have progressively chosen to run multimedia and real-time applications over TCP [Sripanidkulchai 2004].

Services Not Provided by Internet Transport Protocols

We have organized possible transport protocol services along four dimensions: reliable data transfer, throughput, timing, and security.  Which of these services are provided by TCP and UDP? We have already noted that TCP offers reliable end-to-end data transfer. And we also know that TCP can be easily increased at the application layer with SSL to provide security services. But in our brief description of TCP and UDP, conspicuously missing was any mention of throughput or timing guarantees - services not provided by today's Internet transport protocols. Does this mean that time-sensitive applications such as Internet telephony cannot run in today's Internet? The answer is obviously no - the Internet has been hosting time-sensitive applications for many years. These applications often work fairly well because they have been designed to cope, to the greatest extent possible, with this lack of guarantee. We'll investigate many of these design tricks in "Multimedia Networking". However, clever design has its limitations when delay is too much, as is often the case in the public Internet. In summary, today's Internet can often provide satisfactory service to time-sensitive applications, but it cannot provide any timing or bandwidth guarantees.

Figure 2 shows the transport protocols used by some well-known Internet applications. We see that e-mail, remote terminal access, the Web, and file transfer all use TCP. These applications have chosen TCP mainly because TCP provides a reliable data transfer service, guaranteeing that all data will finally get to its destination. We also see that Internet telephony usually runs over UDP. Each side of an Internet phone application needs to send data across the network at some minimum rate (see real-time audio in Figure 1); this is more likely to be possible with UDP than with TCP. Also, Internet phone applications are loss-tolerant, so they do not need the reliable data transfer service provided by TCP.

Popular Internet applications, their application-layer

Addressing Processes

Our discussion above has focused on the transport services between two communication processes. But how does a process indicate which process it wants to communicate with using these services? How does a process running on a host in Amherst, Massachusetts USA specify that it wants to communicate with a specific process running on a host in Bangkok, Thailand? To identify the receiving process, two pieces of information need to be specified: (1) the name or address of the host and (2) an identifier that specifies the receiving process in the destination host.

In the Internet, the host is identified by its IP address. We'll discuss IP addresses in great detail in "The Network Layer", For now, all we need to know is that an IP address is a 32-bit quantity that we can think of as uniquely identifying the host. (However, as we will see in "The Network Layer", the widespread deployment of Network Address Translators (NATs) means that, in practice, a 32-bit IP address alone does not uniquely address a host.)

In addition to knowing the address of the host to which a message is destined, the sending host must also identify the receiving process running in the host. This information is required because in general a host could be running many network applications. A destination port number serves this purpose. Popular applications have been allocated specific port numbers. For instance, a Web server is identified by port number 80. A mail server process (using the SMTP protocol) is identified by port number 25. A list of well-known port numbers for all Internet standard protocols can be found at When a developer creates a new network application, the application must be allocated a new port number. Well study port numbers in detail in "Transport Layer".


transmission rate, tcp connection, throughput, network applications

Copy Right

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.