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

• 7.1 Introduction
  
  
  • This chapter discusses the 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 resend only a few packets -- not whole messages.
    
    
  • In a network that is not packet-switched, a process may have to wait a very long time for another process to finish sending a long message.
    
    
  • Packet switching facilitates the fair sharing of a link.
    
    
    • It works much like round-robin scheduling.
    • It is also similar to a quick-checkout line at a supermarket where shoppers are limited to ten or fewer items.
    • 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.
    
    
  • The text uses the term "frame" to denote some standard kind of packet.
    
    
  • The term "packet" is a general term -- not associated with any particular standard.
    
    
  • It can be 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. For example, they are not needed if packets all have the same size, However in error situations such as after crashes, they are useful for helping receivers "sync up."
    
    
  
• 7.5 Byte Stuffing
  
  
  • We can use a system called byte stuffing to deal with soh's and eot's included by the sender in the data part of a packet. These could confuse the receiver. These internal occurrences 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 chooses the parity bit so that the total number of 1-bits in the sequence (including the parity bit) is even. For example, the decimal ASCII code for 'h' is 104. For 'i' the decimal code is 105. In 7-bit binary, 104 is 1101000 and 105 is 1101001. We would say "hi" by sending these two 8-bit codes: 11010001 11010010. 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 that an error occurred - because the total number of 1-bits will be odd.
    
    
  • When the hardware detects a parity error, typically the receiving software would request that the character be retransmitted.
    
    
• 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 the 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 retransmission 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