(Latest Revision:
Sun Mar 11 20:32:39 PDT 2007
)
Notes On Chapter Sixteen
-- Protocols And Layering
- 16.1 Introduction
- This chapter
- relates the need for network protocol software, and
- describes desirable design characteristics of such software.
- 16.2 The Need For Protocols
- Application programs need to have a
simplified set of commands for using network facilities.
- To accomplish that, specialized "protocol software" between
application and network hardware must exist.
- Protocol software translates simple service requests from
applications into complex sets of commands that operate the
network hardware.
- Protocol software consolidates complex sets of information
and results that come in from the network and translates
them into a format that is easily understood by application
programs.
- A communications protocol is a
set of rules that specify when and how communication shall be
conducted.
- Protocols may include specifications on such things as
language to be used and message formats.
- Protocols may stipulate what messages must be sent and when
they must be sent.
- Protocols may dicate what messages must be answered and what
form the answers must take.
- 16.3 Protocol Suites
- The design of protocol software is in many ways a typical software
design problem.
- Well-known (modular) design guidelines
apply:
- Divide up the work to be done by the software into small,
separate, simple, managable units, each of which correctly
and efficiently performs a desired set of related
operations.
- Give the units (modules) simple easy-to-use interfaces and
create the software by joining together the units into a
coherent whole.
- Avoid redundancy and duplication of effort.
- Build in the required error and exception handling
capabilities.
- It is customary to design the protocols themselves in a modular
fashion. We have families (suites) of
related protocols that are designed to interoperate and cooperate
in performing the overall task of enabling communications.
- The major units of the protocol software are modules that
implement the individual member protocols of the protocol family.
- Each major module may be further subdivided into smaller, more
managable submodules.
- 16.4 A Plan For Protocol Design
- Often protocol software modules are structured with a layered design.
- The layering model seems well suited to the problem of
implementing communications.
- 16.5 The Seven Layers
- In the layering model, the pattern of interaction of the modules
is very simple. Each module (layer)
interacts with at most two other layers: the layer "above" and
the layer "below."
- The International Organization for
Standardization (ISO) defined something called the Seven
Layer Reference Model. This model is often used as an
illustrative example of the concept of a layered protocol
software design.
- The ISO model is interesting and somewhat useful for illustrative
purposes, but it is not considered a completely practical model.
- The names of the seven layers, together with a short description
of the assigned function of each layer follows:
- Layer 1: Physical Layer
(moves bits through the basic network hardware)
- Layer 2: Data Link Layer
(organizes data into frames, transmits and receives
frames)
- Layer 3: Network Layer
(handles addressing and routing)
- Layer 4: Transport Layer
(insures that data reliably gets to its intended
destination)
- Layer 5: Session Layer
(establishes a session -- a sort of virtual connection --
between the source and target software on the communicating
hosts)
- Layer 6: Presentation Layer
(responsible for translating between different data
representations used by communicating hosts)
- Layer 7: Applications Layer
(this is the interface between the network protocol software
and the application that needs to use the network)
- 16.6 Stacks: Layered Software
- The concept of layered design requires
that data move down the stack, across the network, and back up
the stack:
- data leaves the sending software on the source host
- it then "passes down through the layers" on the source host
from the top layer to the bottom layer,
- then the data moves across the physical network,
- it then "passes up through the layers" on the target host
from bottom to top,
- whereupon it is handed off to the destination software
application running on the receiving host.
- 16.7 How Layered Software Works
- The concept of layered design requires that each protocol layer
perform peer-to-peer communication. For example, when the data
link layer places a checksum in a frame and passes the frame
along to the physical layer, it is the data link layer on the
receiving host that examines the checksum.
- 16.8 Multiple, Nested Headers
- Typically each protocol layer adds a header to the beginning of a
frame before passing it down to the layer below.
- There are variations of this that may happen at a given layer --
byte stuffing or appending a trailer, for example.
- 16.9 The Scientific Basis For Layering
- The concept of layered design requires that the following
layering principle be followed:
- "layer N software on the destination
computer must receive the exact messages sent by layer N
software on the sending computer."
- In other words, each layer communicates with the same layer on
its peer.
- In order for the layering principle to hold, the changes that
each protocol layer makes to an outgoing frame must be reversed
exactly by the peer layer on the receiving host before it passes
the frame to the next layer up.
- An important advantage of all the strict
requirements related to the concept of layered design is that
each layer of a protocol stack can be designed, implemented and
tested completely independently of the other layers.
- This is has the effect of greatly simplifying the (usually
arduous) task of creating protocol software.
- 16.10 Techniques Protocols Use (to avoid
reliable transport failures.)
- 16.10.1 Sequencing For Out-Of-Order
Delivery
- When a mesage is divided up and sent as a series of packets,
the packets can travel by different paths across the network
and that makes it possible for them to arrive out of order.
- The receiving host must reassemble the message in the correct
order.
- A protocol layer on the sender puts a serial number on each
packet.
- The peer layer on the receiver uses the numbers to order the
packets. It holds aside packets that have arrive out of
order and passes a correctly ordered sequence of packets to
the next layer up, with no gaps.
- 16.10.2 Sequencing To Eliminate Duplicate
Packets
- Packets may be resent, resulting in duplicate packets being
received. The receiver can detect this error by checking for
duplicate sequence numbers.
- 16.10.3 Retransmitting Lost Packets
- When networks are congested the queues in routers can get
full to overflowing.
- This means that packets that are sent may be "dropped" by a
router and never arrive at the intended destination.
- Transmission errors can corrupt packets. They are rejected
and they too are never received by the intended recipient.
- To assure reliable delivery, senders and receivers agree to
make positive acknowledgement with
retransmission a part of their protocol.
- X sends a packet to Y and starts a timer that counts down
from some limit toward zero. If an acknowledgement comes
back from Y before the timer reaches zero, X "cancels" the
timer. If not, X retransmits the packet after the timer
reaches zero and starts a new timer. This repeats until X
gets an ACK from Y (or until X decides to give up).
- It is possible that X will retransmit a packet that is not
really lost but just slow in getting to its destination --
or it may be that the ACK from Y is slow. In either case,
the result may be that Y receives duplicate packets.
Therefore Y must know how to handle this error.
- 16.10.4 Avoiding Replay Caused By
Excessive Delay
- A very late packet from a first communication
session can arrive during a second, subsequent communication
session with a plausible sequence number. It could be
mistaken as a packet belonging to the second communication
session. This error is known as a replay error.
- To prevent errors caused by replay, protocols assign a
serial number to each conversation, as well as to each
packet belonging to a conversation.
- For example, three packets of conversation #1 might be
numbered this way: (1,0), (1,1), (1,2).
- Six packets of conversation #2 might be numbered: (2,0),
(2,1), (2,2), (2,3), (2,4), (2,5).
- 16.10.5 Flow Control To Prevent Data
Overrun
- If a sender sends data too fast it may overrun (swamp) the
target or some router in between the sender and target.
This will prevent the target from receiving all the data
intact.
- Flow control is required.
- The simplest form of flow control is stop-and-go:
The sender sends one packet at a time and waits for each
packet to be ACK'd by the receiver before sending another
packet.
- Stop-and-go typically wastes bandwidth because the sender
sends just one packet and then while it waits for the ACK,
sufficient time elapses to send a vast number of additional
packets, a high percentage of which the target would be able
to receive intact.
- A technique called sliding window usually achieves
higher throughput.
- The fundamental idea of sliding window is that sender X and
receiver Y agree on a number W called the window size.
- X is allowed to send as much as it wants whenever it
likes, as long as no more than W of the packets X has sent
remain unacknowledged by Y.
- For example if the window size W is 50 and X has received
ACK's for all but 14 of the packets it has sent to Y, then X
currently has permission to send 36 packets to Y any time it
likes. It can immediately send 36 packets if it wants to.
- What makes this work is that the receiver will have the
capacity to buffer (queue) a certain number of packet. If a
packet arrives when the buffer is full, there will be an
overrun. However there is no problem if packets arrive when
the buffer is not full. Throughput will be better if
packets are sent immediately at times when the buffer is not
full.
- Usually the window size is equal to the buffer size or
slightly less.
- Typically X sends W packets at almost the same time, receives
ACK's for all of them at about the same time, sends W more, and
so on. This yields a throughput of about T = W*Tg,
where Tg is the throughput one gets with stop-and-go
flow control.
- 16.10.6 Mechanisms To Avoid Network
Congestion
- Congestion arises in network flows. For example when two
fiber links carrying more than half capacity traffic
fan-in to a single fiber link connected by a switch,
the queue in the switch can overrun and then some of the
packets entering the switch will be "dropped."
- To handle this problem, senders can
reduce the window size after retransmitting a packet. It is
very likely that the timer expired because of congestion,
and reducing the window size will cause the sender to
slow down.
- There are alternatives: for example a congested switch can
send a message back to a source and ask it to slow down. The
problem with this is that it puts a burden of doing
additional processing on a switch at a time when it is having
trouble keeping up with the current load.
- 16.11 The Art Of Protocol Design
- Even when software designers employ a layered-design approach,
network protocol design is a difficult task.
- Features of the protocols tend to interact in unexpected ways
that can cause problems.
- For example the interplay between sliding
window and congestion control caused problems during the
development of the Internet. The problem was akin to the
excessive cycling one sees when a heating system continually
turns itself on and off.
- Senders would agressively increase window size and start to chew
up bandwidth. This would cause congestion. Senders would then
aggressively decrease window size. This would lead to rapid
reduction in congestion and under-utilization of bandwidth. The
situation would tend to oscillate without achieving a stable
flow, and therefore overall throughput characteristics were
unnacceptably sub-optimal.
- 16.12 Summary