Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

Why TCP Must Monitor and Deal With Internetwork Congestion

Flow control is a very important part of regulating the transmission of data between devices,

but it is limited in the following respect: it only considers what is going on within each of the

devices on the connection, and not what is happening in devices between them. In fact, this

“self-centeredness” is symptomatic of architectural layering. Since we are dealing with how

TCP works between a typical server and client at layer four, we don't worry about how data

gets between them; that's the job of the Internet Protocol at layer three.

In practice, what is going on at layer three can be quite important. Considered from an

abstract point of view, our server and client may be connected “directly” using TCP, but all

the segments we transmit are carried across an internetwork of networks and routers

between them. These networks and routers are also carrying data from many other connec-

tions and higher-layer protocols. If the internetwork becomes very busy, the speed at which

segments are carried between the endpoints of our connection will be reduced, and they

could even be dropped. This is called congestion.

Again, at the TCP level, there is no way to directly comprehend what is causing congestion

or why. It is perceived simply as inefficiencies in moving data from one device to another,

through the need for some segments to be retransmitted. However, even though TCP is

mostly oblivious of what is happening on the internetwork, it must be smart enough to

understand how to deal with congestion and not exacerbate it.

Recall that each segment that is transmitted is placed on the retransmission queue with a

retransmission timer. Now, suppose congestion dramatically increased on the internetwork,

and there were no mechanisms in place to handle congestion. Segments would be delayed

or dropped, which would cause them to time out and be retransmitted. This would increase

the amount of traffic on the internetwork between our client and server. Furthermore, there

might be thousands of other TCP connections behaving similarly. Each would keep retrans-

mitting more and more segments, increasing congestion further, leading to a vicious circle.

Performance of the entire internetwork would decrease dramatically, resulting in a condition

called congestion collapse.

The message is clear: TCP cannot just ignore what is happening on the internetwork

between its connection endpoints. To this end, TCP includes several specific algorithms

that are designed to respond to congestion, or avoid it in the first place. Many of these

techniques can be considered, in a way, to be methods by which a TCP connection is made

less “selfish”—that is, it tries to take into account the existence of other users of the inter-

network over which it operates. While no single connection by itself can solve congestion of

an entire internetwork, having all devices implement these measures collectively reduces

congestion due to TCP.

The first issue is that we need to know when congestion is taking place. By definition,

congestion means intermediate devices—routers—are overloaded. Routers respond to

overloading by dropping datagrams. When these datagrams contain TCP segments, the

segments don't reach their destination, and they are therefore left unacknowledged and will

eventually expire and be retransmitted. This means that when a device sends TCP

segments and does not receive acknowledgments for them, it can be assumed that in most

cases, they have been dropped by intermediate devices due to congestion. By detecting

the rate at which segments are sent and not acknowledged, a TCP device can infer the

level of congestion on the network between itself and its TCP connection peer.

TCP Congestion Handling Mechanisms

We must then decide what to do with this information. The main TCP standard, RFC 793,

includes very little information about TCP congestion handling issues. That is because early

versions of TCP based solely on this standard didn't include congestion handling

measures—it was problems with these early implementations that lead to the discovery that

congestion was an important issue. The measures used in modern devices were developed

over the years, and eventually documented in RFC 2001, TCP Slow Start, Congestion

Avoidance, Fast Retransmit, and Fast Recovery Algorithms.

Here is a simplified description of each of the four techniques that comprise the name of

this standard.

Slow Start

In the original implementation of TCP, as soon as a connection was established between

two devices, they could each go “hog wild”, sending segments as fast as they liked as long

as there was room in the other device's receive window. In a busy internetwork the sudden

appearance of a large amount of new traffic could exacerbate any existing congestion.

To alleviate this, modern TCP devices are restrained in the rate at which they initially send

segments. Each sender is at first restricted to sending only an amount of data equal to one

“full-sized” segment—that is, equal to the MSS value for the connection. Each time an

acknowledgment is received, the amount of data the device can send is increased by the

size of another full-sized segment. Thus, the device “starts slow” in terms of how much data

it can send, with the amount it sends increasing until either the full window size is reached

or congestion is detected on the link. In the latter case, the congestion avoidance feature,

described below, is used.

Congestion Avoidance

When potential congestion is detected on a TCP link, a device responds by throttling back

the rate at which it sends segments. A special algorithm is used that allows the device to

drop the rate at which segments are sent quickly when congestion occurs. The device then

uses the Slow Start algorithm just above to gradually increase the transmission rate back

up again to try to maximize throughput without congestion occurring again.

Fast Retransmit

We’ve already seen in our look at TCP segment retransmission that when segments are

received by a device out of order (meaning, non-contiguously), the recipient will only

acknowledge the ones received contiguously. The Acknowledgment Number will specify the

sequence number of the byte it expects to receive next. So, in the example given in that

topic, Segment #1 and #2 were acknowledged while #4 was not, because #3 was not

received.

It is possible for a TCP device to in fact respond with an acknowledgment when it receives

an out-of-order segment, simply “reiterating” that it is stuck waiting for a particular byte

number. So, when the client in that example receives Segment #4 and not Segment #3, it

could send back an Acknowledgment saying “I am expecting the first byte of Segment #3

next”.

Now, suppose this happens over and over. The server, not realizing that Segment #3 was

lost, sends Segment #5, #6 and so on. Each time one is received, the client sends back an

acknowledgment specifying the first byte number of Segment #3. Eventually, the server can

reasonably conclude that Segment #3 is lost, even if its retransmission timer has not

expired.

The Fast Retransmit feature dictates that if three or more of these acknowledgments are

received, all saying “I want the segment starting with byte #N”, then it's probable that the

segment starting with byte #N has been lost, usually because it was dropped due to

congestion. In this case, the device will immediately retransmit the missing segment without

going through the normal retransmission queue process. This improves performance by

eliminating delays that would suspend effective data flow on the link.

Fast Recovery

When Fast Retransmit is used to re-send a lost segment, the device using it performs

Congestion Avoidance, but does not use Slow Start to increase the transmission rate back

up again. The rationale for this is that since multiple ACKs were received by the sender all

indicating receipt of out-of-order segments, this indicates that several segments have

already been removed from the flow of segments between the two devices. For efficiency

reasons, then, the transmission rate can be increased more quickly than when congestion

occurs in other ways. This improves performance compared to using the regular

Congestion Avoidance algorithm after Fast Retransmit.

Relationship of Congestion Handling Mechanisms

In practice, these features are all related to each other. Slow Start and Congestion

Avoidance are distinct algorithms but are implemented using a single mechanism, involving

the definition of a Congestion Window that limits the size of transmissions and whose size

is increased or decreased depending on congestion levels. Fast Retransmit and Fast

Recovery are implemented as changes to the mechanism that implements Slow Start and

Congestion Avoidance.

I realize that this is somewhat cryptic; congestion handling is a rather complex process. If

you want to learn more, RFC 2001 contains the technical details, showing how each of the

algorithms is implemented in each device. I have specifically omitted those details from this

topic since I feel my summary descriptions are already complicated enough, and my goal

was simply to help you get a feel for how congestion is handled in TCP in general terms.

Key Concept: TCP flow control is an essential part of regulating the traffic flow

between TCP devices, but takes into account only how busy the two TCP endpoints

are. It is also important to take into account the possibility of congestion of the

networks over which any TCP session is established, which can lead to inefficiency through

dropped segments. To deal with congestion and avoid contributing to it unnecessarily,

modern TCP implementations include a set of congestion avoidance algorithms that alter

the normal operation of the sliding window system to ensure more efficient overall

operation.

Summary Comparison of TCP/IP Transport Layer Protocols (UDP

and TCP)

The User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) are the

“siblings” of the transport layer in the TCP/IP protocol suite. They perform the same role,

providing an interface between applications and the data-moving capabilities of the Internet

Protocol (IP), but they do it in very different ways. The two protocols thus provide choice to

higher-layer protocols, allowing each to select the appropriate one depending on its needs.

I have described UDP and TCP in detail in their own sections. However, these sections take

some time to read; the UDP section is several pages and the TCP section has many more!

For your convenience I have included here Table 161, which helps illustrate the most

important basic attributes of both protocols and how they contrast with each other:

Table 161: Summary Comparison of UDP and TCP

Characteristic /

Description

UDP TCP

General Description

Simple, high-speed, low-functionality

“wrapper” that interfaces applications to

the network layer and does little else.

Full-featured protocol that allows appli-

cations to send data reliably without

worrying about network layer issues.

Protocol Connection

Setup

Connectionless; data is sent without

setup.

Connection-oriented; connection must

be established prior to transmission.

Data Interface To

Application

Message-based; data is sent in discrete

packages by the application.

Stream-based; data is sent by the

application with no particular structure.

Reliability and

Acknowledgments

Unreliable, best-effort delivery without

acknowledgments.

Reliable delivery of messages; all data

is acknowledged.

Retransmissions

Not performed. Application must detect

lost data and retransmit if needed.

Delivery of all data is managed, and

lost data is retransmitted automatically.

Features Provided to

Manage Flow of Data

None

Flow control using sliding windows;

window size adjustment heuristics;

congestion avoidance algorithms.

Overhead Very low Low, but higher than UDP

Transmission Speed Very high High, but not as high as UDP

Data Quantity

Suitability

Small to moderate amounts of data (up

to a few hundred bytes)

Small to very large amounts of data

(up to gigabytes)

Types of Applications

That Use The Protocol

Applications where data delivery speed

matters more than completeness,

where small amounts of data are sent;

or where multicast/broadcast are used.

Most protocols and applications

sending data that must be received

reliably, including most file and

message transfer protocols.

Well-Known

Applications and

Protocols

Multimedia applications, DNS, BOOTP,

DHCP, TFTP, SNMP, RIP, NFS (early

versions)

FTP, Telnet, SMTP, DNS, HTTP, POP,

NNTP, IMAP, BGP, IRC, NFS (later

versions)

TCP/IP Application Layer Protocols, Services and

Applications (OSI Layers 5, 6 and 7)

The OSI Reference Model is used to describe the architecture of networking protocols and

technologies and to show how they relate to one another. In the chapter describing the OSI

model, I mentioned that its seven layers could be organized into two layer groupings: the

lower layers (1 through 4) and the upper layers (5 through 7). While there are certainly other

ways to divide the OSI layers, I feel this split best reflects the different roles that the layers

play in a network.

The lower layers are concerned primarily with the mechanics of formatting, encoding and

sending data over a network; they involve software elements but are often closely

associated with networking hardware devices. In contrast, the upper layers are concerned

mainly with user interaction and the implementation of software applications, protocols and

services that let us actually make use of the network. These elements generally don't need

to worry about details, relying on the lower layers to ensure that data gets to where it needs

to go reliably.

In this chapter I describe the details of the many protocols and applications that run on the

upper layers in modern networks and internetworks. The organization of this chapter is

quite different than the previous one. I felt that there was benefit to explaining the technol-

ogies in each of the lower layers separately. This is possible because with a few exceptions,

the dividing lines between the lower layers are fairly well-established, and this helped show

how the layers differ.

The upper layers are much more difficult to separate from each other, because there are

many technologies and applications that implement more than one of layers 5 through 7.

Furthermore, even differentiating between these layers becomes less important near the

top of the networking stack. In fact, the TCP/IP protocol suite uses an architecture that

lumps all the higher layers together anyway.

For these reasons, this chapter is divided functionally and not by layer. It contains four

different sections that cover distinct higher-layer protocol and application areas. The first

discusses naming system, especially the TCP/IP Domain Name System. The second

overviews file and resource sharing protocols, with a focus on the Network File System.

The third covers network configuration and management protocols, which includes the host

configuration protocols BOOTP and DHCP. The last and largest section covers end-user

applications and application protocols, including general file transfer, electronic mail,

Usenet, the World Wide Web, interactive protocols (such as Telnet) and administration

utilities.

Name Systems and TCP/IP Name Registration and Name

Resolution

Humans and computers first started dealing with each other several decades ago. The

relationship between man (and woman!) and machine has been a pretty good one overall,

and this is reflected in the fact that while computers were once just the province of techies,

they are now mainstream. However, there are areas where humans and computers simply

don't see eye to eye. One of these is in the way that we deal with information.

Computers work best with numbers, while most people prefer… not to work with numbers.

This fundamental disconnect represented a problem for the designers of networking

technology. It made sense from a technical standpoint to design addressing schemes for

networks and internetworks using simple numeric identifiers, for simplicity and efficiency.

Unfortunately, identifying computers using numeric addresses is cumbersome for people,

and becomes more so as the number of devices on a network increases.

To solve this problem, the techies went to work, and came up with name systems for

networks. These mechanisms allow computers to continue to use simple, efficient numeric

addresses, while letting humans specify easier-to-remember names that identify them. This

way, everyone is happy. Well, almost everyone I guess. These systems mean those of us

studying networks have one more thing to learn. ☺

In this section I explain both the theory and practice behind networking name systems. I

begin with a section that describes the motivation for name systems and the important

concepts and techniques behind how they work. I then have a large section devoted to the

name systems used for TCP/IP. This includes both the very important Domain Name

System (DNS), as well as the older host table method that preceded it.

Name System Issues, Concepts and Techniques

Name systems can be considered in some ways the “diplomats” of the networking protocol

stack. Just as a political diplomat is skilled at speaking multiple language and ensuring

good communications between those who may view the world in different ways, name

systems bridge the gulf between the numeric addresses that computers like to use, and the

simpler names that humans prefer.

Before looking at specific name systems, I felt it made sense to discuss them generally.

This will help us understand both the reasons why these systems are important, and also

the concepts that underlie all name systems regardless of specific implementation. I begin

this section with an overview of name systems and a discussion of why they were created. I

then discuss the different main functions of a name system: the name space, name regis-

tration and name resolution. I then expand upon this functional overview, illustrating how

name spaces and architectures work, the issues behind name registration and adminis-

tration, and finally, name resolution techniques and the practical issues in the resolution

process.

Since this is an introductory section, I have attempted to stick to general descriptions and

not make too many mentions of specific name systems in the topics here. However, I like to

use examples to explain concepts and for this purpose do make reference to the TCP/IP

Domain Name System (DNS) at times. However, you do not need to be familiar with DNS to

follow this section.

Name System Overview and Motivation

In the introduction to this section on name systems I mentioned one of several important

differences between humans and computers: how we prefer to deal with information.

Computers work with numbers, while very few of us humans like to do so. This distinction

becomes particularly important when we look at how identifiers or addresses are assigned

to network devices.

Symbolic Names for Addressing

To a computer, there is no problem with simply assigning a number to each device on the

network and using those numbers to move information around. Your computer would be

perfectly happy if you assigned a number like 341,481,178,295 to it and all the other

machines on your network, and then issued commands such as “send this file to machine

56,712,489,901”. However, most humans don't want to use a network in this manner. These

long cryptic numbers don't mean anything to them. They want to tell their machine “send

this file to Joe's computer”; “print this on the color laser in the Sales department”, or “check

CNN’s Web site to see what the latest headlines are”.

It is this disconnect that led to the development of name systems. These technologies allow

computers on a network to be given both a conventional numeric address and also a more

“user-friendly” human-readable name. This name is comprised of letters, numbers and

other special symbols, and is sometimes called a symbolic name; it can be used as an

alternative form of addressing for devices. The name system takes care of the functions

necessary to manage this system, including ensuring that names are unique, translating

from names to numbers, and managing the list of names and numbers.

A Paradox: Name Systems Are Both Essential and Unnecessary?

What's interesting about name systems is that they are extremely important to networks…

but at the same time, they often aren't strictly necessary for a network to operate. This

seeming paradox is due again to the difference between humans and computers.

Computers only need the numeric addressing scheme, not the “human names” assigned to

them. So the computers and the network can still work—but it will be much harder for us

people to use them!

An example of this can most readily be seen when a problem disables the operation of a

part of the Domain Name System (DNS) used to provide naming services on the Internet.

Technically, DNS isn't needed to use the Internet, because all communications use IP

addresses. This means that even though you might normally access CNN's web site at

“www.cnn.com”, you could instead just use the IP address 64.236.16.20 if DNS wasn't

working.

The problem is that prior to reading this, you probably had no idea what the IP address of

CNN's Web site was, and that's true of almost everyone else who uses their site as well.

Also, you might want to check not just CNN's Web site, but perhaps one, two or twenty

other news sites. It would be difficult to remember the numbers for even a small percentage

of the thousands of different Web sites on the Internet, so each time you wanted to access

a resource you’d have to manually look up its address, as shown in Figure 229.

Factors That Determine the Necessity of a Name System

It's much easier to remember the names of resources; when a name system is imple-

mented, you just enter the name of a device and the name system converts it to an

address, as shown in Figure 230. This is why name systems are so important, even if they

aren't needed by the networking technologies themselves. (In fact, the reliance on name

systems like DNS is so significant that many people don't even realize they can enter IP

addresses into their Web browsers!)

More generally, the importance of a name system depends greatly on the characteristics of

the network upon which it is used. The three main issues in determining the need for a

name system are:

☯ Network Size: If you have a really small network with only a handful of computers,

having human users remember the numeric addresses for these machines is at least

feasible, if not ideal. For example, a small home network with two or three machines

doesn't really need a name system, in theory. If you have thousands or millions of

devices, however, the name system becomes essential.

☯ Address Size and Complexity: The more complex the numeric addressing scheme,

or the larger the numbers used, the more difficult it is for humans to remember the

numbers.

☯ User Base Size and Skill: In the early days of networks, a small number of highly-

skilled and well-trained engineers used them, and these people sometimes just

memorized the numbers of the machines they worked with every day. In modern

networks with thousands or millions of “lay” users, expecting the average person to

remember device numbers is not reasonable.

Looking at these issues, we can see that the trends in today’s networks are all in the

direction of increasing the importance of name systems. Our networks, both private and

public, are growing larger, and we have more people using them, including more people

without a technical background. We are also increasingly moving from small addresses to

Figure 229: Internetwork Access Without A Name System

When there is no name system, a user must know the address of any device he or she wishes to access on

the internetwork. Since most of us have limited memories for numbers, this means each access must be

preceded by an inefficient, tedious manual address look-up.

Look Up Address

Human User Client Server

Enter Address

Request Resource

Process Request

Generate Reply

Process Reply

Access Resource