Outline

• Device Drivers
• Reliable transmission:
  • Acks and Timeouts
  • Types of Acks
  • Alternating Bit Protocol
  • Sliding Window Protocol
  • sequence number size

Device Drivers

• the operating system component that communicates with a device
• does input, output, and management
• lower half is executed at interrupt time:
  • does the actual I/O and management
  • signals the upper half
• upper half is executed at system call time:
  • requests I/O or management functions from lower half
  • usually does resource management
  • tells device to interrupt, to call lower half
• state shared by upper and lower, so synchronization is essential

Device Drivers: upper half

• book, page 140

1. allocate resources
2. enter mutual exclusion, disable interrupts
3. copy data to buffer
4. request transmission, interrupt
5. enable interrupts, exit mutual exclusion

Device Drivers: lower half

• book, page 141-142
• interrupt handler
• clear each interrupt

1. disable interrupts (implicit mutual exclusion)
2. check for errors
3. check for transmit interrupt:
   • signal upper half
4. check for receive interrupt:
   • allocate resources: processes, buffers
   • x-kernel receiver does not signal upper half
5. enable interrupts

Reliable Transmission

• reasons for packet loss:
  • discarding corrupted packets
  • overflowing router queues
  • running out of buffer space on receiver
  • mis-routing or other "software" errors
• general strategy for reliability:
  • sender keeps copies of transmitted packets
  • receiver acknowledges received packets
  • sender discard copies if ack received
  • sender retransmits packet if no ack received by time-out
• packets have to be distinguishable, acks must identify packets

Types of Acks

• cumulative acks, with appropriate timeouts, can do everything the others can do
• other acks can improve performance:
  • with a nak, sender can tell before the timeout that it needs to retransmit
  • with a selective ack, sender can discard buffered copies sooner, since receiver can ack out-of-order packets

In-class exercise

• in groups of up to 4
• 5 minutes: design a reliable transmission system using only one of either naks or selective acks (no cumulative acks)
• 5 minutes: compare your system to one using cumulative acks. Be prepared to have someone in your group speak on the subject

Stop-and-Wait

• Send a packet, wait for ack.
• If ack is not received within timeout, retransmit frame.
• two possibilities:
  1. ack is lost, sender retransmits
  2. ack is received, sender transmits next packet
  receiver must be able to distinguish the two cases
• [ ==> ] we need a 1-bit sequence number to distinguish the two cases

Sliding Window

• Stop-and-Wait with multiple outstanding packets
• window size W
• last ack received by sender is LAR
• sender can send up to LAR + W
• new ack moves LAR, allowing sender to send more packets
• next packet expected by receiver is NPE
• maximum packet expected by receiver is NPE + W - 1
• any packet outside this range is discarded
• cumulative ack sent when NPE changes

Sliding Window

• reliable delivery
• if W >= bandwidth * delay, the "pipe" remains full of bits (if receiver is faster than the network)
• in-order packet delivery is easy
• flow control is easy:
  • receiver could withhold acks (leading to retransmissions)
  • receiver might tell sender to reduce W
• separation of concerns: one mechanism, many functions

Sequence Numbers

• why should receiver discard packets outside the window?
• Stop-and-Wait is sliding window with W=1
• Stop-and-Wait receiver must discard packet other than expected, since it is an old retransmission
• sliding window receiver must be able to distinguish W valid packets from W retransmitted packets
• [ ==> ] sliding window receiver must be able to distinguish 2W different packets
• [ ==> ] sequence number space must be at least 2W, e.g. we need at least 5 bits if W=16

Project Status

1. how many people have read the RFC?
2. how many people have completed the design of their system?
3. how many people have started implementing their system?
4. how many people have tested the simulation code?
5. how many people are done?