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 dictate 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, manageable 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 sub modules.
    
    
• 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. This layer is not software - it is implemented in the 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:
    
    
    1. data leaves the sending software on the source host
       
       
    2. it then "passes down through the layers" on the source host from the top layer to the bottom layer,
       
       
    3. then the data moves across the physical network,
       
       
    4. it then "passes up through the layers" on the target host from bottom to top,
       
       
    5. whereupon it is handed off to the destination software application running on the receiving host.
       
       
  • Computers can run more than one protocol stack at the same time, sharing the same physical network for transport. Type fields in frames at the physical level allow system software to direct packets to the correct protocol software.
    
    
• 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 message is divided up and sent as a series of packets, the packets may travel by different paths across the network and so it is possible they will not arrive in the same order that they were sent.
      
      
    • 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 arrived 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 acknowledgment 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 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 packets. 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*T_g, where T_g is the throughput one gets with stop-and-go flow control.
      
      Of course, this throughput cannot exceed the underlying limitations on the bandwidth of the communication channel.
      
      
    • 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 aggressively 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 unacceptably sub-optimal.
      
      
  • 16.12 Summary
    
    

  ---