Notes On Chapter Seven -- Packets, Frames, And Error Detection

• 7.1 Introduction
  
  
  • This chapter discusses packet concept, packet implementation, coordination of sender and receiver, and error detection.
    
    
• 7.2 The Concept Of Packets
  
  
  • Most network systems divide messages into small blocks of data called packets.
    
    
  • Packets are useful for error control. A recipient checks each packet and requests a retransmission when necessary. With luck, it is necessary to re-send only a few packets -- not whole messages.
    
    
  • If networks did not use packet-switching then senders of very short messages would sometimes have to wait a very long time for senders of long messages to finish using the communication link.
    
    
  • Packet switching facilitates the fair sharing of a link.
    
    
    • It works much like round-robin scheduling.
    • It is also similar to what retailers are doing when they refuse to sell more than a certain number of items to a customer at any one time.
    • Another similar practice: a large family shares a telephone and all members agree to make only short calls.
    • A sender cannot tie up the link for any longer than the time it takes to send one packet.
    • After each packet is sent, the other senders have a chance to send a packet.
    • Usually, no sender has to wait very long to send a packet.
    
    
    
• 7.3 Packets And Time-Division Multiplexing
  
  
  • Packet switching is a form of time-division multiplexing.
    
    
  • Typically it will not take host X long to send a short message, even if Y is sending a long message at the same time.
    
    
• 7.4 Packets And Hardware Frames
  
  
  • standards must define the design of packets.
    
    
  • we will use the term "frame" to denote some standard kind of packet.
    
    
  • the term "packet" will be the general term -- not associated with any particular standard.
    
    
  • It is useful to have the ends of packets marked with special characters such as "soh" (start of header) and "eot" (end of transmission). These markers are not always needed, if packets all have the same size, for example. However in error situations such as after crashes, they are useful for helping receivers "sync up."
    
    
• 7.5 Byte Stuffing
  
  
  • We can use system called byte stuffing to deal with soh's and eot's included by the sender in the *data* payload of a packet. These could confuse the receiver. These internal occurences are changed to something else, just while in transit, and then changed back by the receiver.
    
    
  • For example we can replace "soh" with esc-x, "eot" with esc-y, and esc with esc-z.
    
    
• 7.6 Transmission Errors
  
  
  • Lightning, power surges, and other such interference can introduce error into transmissions and even create the appearance of transmissions where none exist.
    
    
  • Communication protocols must be designed to compensate for the effects of such transmission errors, even though this adds considerably to the complexity of these protocols.
    
    
• 7.7 Parity Bits And Parity Checking
  
  
  • The RS-232 hardware checks that the voltage stays constant while a bit is being sent, and that the stop bit occurs at the proper time. If a check fails the hardware declares an error.
    
    
  • Most RS-232 circuits also do a parity check. The sender adds a parity bit to each character before sending. With the "even parity" scheme, the sender choosed the parity bit so that the total number of 1 bits in the character sequence is even. If one of the bits in the character is "inverted" due to interference, i.e. if a single 1 is changed to a 0 or vice versa, then the receiver will detect the problem because the total number of 1 bits will be odd. In this case the hardware will declare an error.
    
    
  • When the hardware declares an error, the receiving software can request that the character be re-transmitted.
    
    
• 7.8 Probability, Mathematics, And Error Detection
  
  
  • Parity checks can detect only 1-bit errors, 3-bit errors, and so forth: errors in an odd number of bits.
    
    
  • There are more powerful and sophisticated "checksum" methods in use. The sender uses some of the message bits to compute "check bits" and then sends these extra bits along with the message bits. The receiver performs the computation again and sees if the result is a different set of check bits. If so, an error is declared. No checksum scheme is perfect but it is not very difficult or costly to achieve a very low probability of accepting "bad data."
    
    
• 7.9 Detecting Errors With Checksums
  
  
  • We can treat each 16-bit sequence of bits as an integer, add them all, add carry bits too, and use the resulting 16-bit quantity as a checksum.
    
    
  • This method is simple and efficient but there are common transmission errors that it does not detect.
    
    
• 7.10 Detecting Errors With Cyclic Redundancy Checks
  
  
• 7.11 Combining Building Blocks
  
  
  • A cyclic redundancy check (CRC) is a type of "checksum" that is easy to calculate using shift registers and xor gates. Also, it does a good job of "mixing up" all the bits of the message.
    
    
  • The resulting check bits are quite good at detecting common errors.
    
    
• 7.12 Burst Errors
  
  
  • A burst error is a common kind of error caused by interference where many bits in a row will all be changed to the same value. For example we might get three characters in a row that appear to be all ones.
    
    
  • Suppose that 3rd and 5th bits of every character transmitted are always zero. This is an example of a vertical error -- where the same bit positions are consistently either held constant or inverted. Faulty hardware often introduces vertical error.
    
    
  • CRC's do a good job of detecting burst errors and vertical errors. These are common kinds of errors that ordinary checksums are not too good at detecting.
    
    
• 7.13 Frame Format And Error Detection Mechanisms
  
  
  • Typically a CRC is computed for each frame (packet) sent by the network. The sending software sends the frame first and the CRC immediately afterward. The receiver uses the CRC to check for error and request a retransmittal of the frame if an error is detected.
    
    
  • It's important that the sender and receiver have an exact agreement on the "formula" for the CRC.
    
    
• 7.14 Summary