Packet scheduling

• packet scheduling
• FIFO queueing
• fair queueing

Packet Scheduling

• routers have a queue of outgoing packets for each interface
• any number of threads can place packets in the queue
• a single thread removes and sends the front packet in the queue whenever the previous packet has been sent
• there can be many strategies for placing packets in the queue!
• there could also be multiple queues, or priority queues

FIFO Queuing

• each packet is placed at the end of the queue
• packets (that take the same route) are never reordered
• delay is proportional to queue size
• works reasonably well in Internet, with TCP congestion control
• if all but one sender do congestion control, and one does not, the one that doesn't (IP telephony, multicasting) might grab much of the bandwidth

Fairness

• "everyone" gets the same treatment
• hard to do in a distributed system:
• local fairness (every flow gets the same treatment on this router) discriminates against flows that cross more routers (parking garage problem)
• global fairness requires global co-ordination, so local fairness is often the best we are willing to do

Fair Queueing

• one FIFO queue for each flow
• packets are taken in round-robin order from each queue that has them
• problem: large packets counted the same as small packets
• logically, we want to send one bit from each flow in round-robin order

Fair Queueing with Different size packets

• the virtual clock ticks once for each bit sent from each of the queues
• so if there are more active queues, that means the virtual clock advances more slowly
• the virtual finish time for a packet is its start "time" plus the size of the packet
• the virtual start time of a packet is the largest of:
  the finish time for the previous packet in the queue (a computed quantity), or
  • the actual virtual arrival time of the packet
• to be fair, select and transmit the packet with the lowest virtual finish time

TCP Review

• state management: connection setup and teardown, Transmission Control Block (TCB)
• reliable transmission via sequence numbers, acknowledgements
• flow control to avoid overwhelming receiver:
  • hard to obtain both reliability and performance
  • acknowledgements are not acknowledged, but crucial information is carried in the acknowledgements (e.g. the window size)
• congestion control to avoid overwhelming network (or to slow down when we do) requires adaptive timer
• "good enough" (TCP Reno) may be preferable to "better" (TCP Vegas)

Our network so far

• TCP and IP (and UDP)
• reliable byte-stream and packet transmission among applications
• only application so far: DNS
• only Data Link layer so far: SLIP
• only Physical layer so far: serial lines, which are limited in speed (about 100,000 b/s max), distance (typically within a building), and number of hosts (at most two hosts per serial line)