Data Link Protocols

1. Data Link Protocols By Erik Reeber

2. Goals • Use SPIN to model-check successively more complex protocols • Using the protocols in Tannenbaum’s 3rd Edition of Computer Networks • Compare this approach to using other verification tools

3. A Layered Packet Physical Data Link Network … User Data Background • Processes communicate using layers • Each layer provides services to higher-level layers and ultimately to the user

4. Data Link Layer • Sits between the physical and network layers • For our purposes: provides non-lossy, error-free, and ordered communication for the network layer • The physical layer will provide error-free communication, but packets may get lost.

5. Specification • Safety: [] ! Bad_network_packet • Liveness: [] (network_message_sent -> <> network_message_received) • A packet is “bad” if it is not the packet expected

6. Problems with the Spec • Ideally, requires an infinite queue to check • Ideally, any packet can be sent. This can be implemented in SPIN with: packet new_packet; do :: (i < PKT_SIZE) -> if :: true-> new_packet.p[i]++ :: true-> skip fi :: else -> break od

7. Simplifications • Use a finite queue, that loops around • Use a packet size of 1, and pick between 0 and 1. 0,4,8 12,… 1 2 3 packet new_packet; if :: true-> new_packet.p[0]=0 :: true-> new_packet.p[0]=1 fi

8. Why OK? • Finite-queue of k elements: not always ok (consider k=2, and drop 2). We must prove: [] ((network_sent – network_received) < k). • Packet size 1: ok, since the physical layer can only lose packets. Any packet loss or reordering can be detected with just 1 bit.

9. Protocol 1 • Assumes no packets are lost by the physical layer • Assumes receiver infinitely fast sender() { packet buffer; frame s; do :: true -> A_from_network?to_sender(buffer); s.info.p=buffer.p; A_to_physical!to_physical(s) } receiver() { packet pack; frame r,s; do :: true -> B_wait_for_event?to_receiver(); B_from_physical_layer?to_receiver(r); pack.info.p = r.info.p; B_to_network!to_network(pack) }

10. Notes on Protocol 1 • I use separate processes for the network, physical, and data-link processes (6 processes already!) • Wire is multiple channel, all other communication is done with 0 width (synchronous) channels. • Need to add a constraint to both properties: [] (num_packets_in_DLR < 2) • With the constraint, both properties went through SPIN 

11. Protocol 2 • No longer assume infinite speed receiver • Instead, receiver sends ack back to sender B A frame ack

12. Notes on Protocol 2 • Up to 8 processes! • Model-checker getting slow (liveness proof went 252,700 states deep) • Never more than one message being dealt with at a time • Both checks went through 

13. Protocol 2_5 • Tannenbaum mentions a simple extension to protocol 2 to make it handle dropped messages. Just set a timer on the sender, if the timer buzzes resend. • Why doesn’t that work? • Safety proofs goes through if add the condition that the ack is never dropped 

14. Protocol 3 • Truly handle lost messages • Add a one bit sequence number to the message and the ack. Also timeout as in 2_5. • But how does one implement a timer in SPIN…

15. Timer Implementations • Use the timeout keyword: • Had problems with the timeout keyword sticking • Use the scheduler: timer() { do :: timeout -> A_wait_for_event!to_sender(time_out) od } timer() { do :: true -> A_wait_for_event!to_sender(time_out) od }

16. More timer implementations • Use non-determinism: timer() { do :: true -> do :: true -> skip :: true -> break od; A_wait_for_event!to_sender(time_out) od }

17. Notes on protocol 3 • Proved liveness with the scheduler’s timer and safety under the timeout keyword. • Looking for the right timer implementation • Made a pretty and an ugly version of protocol 3. The ugly version gets rid of the physical senders

18. Protocol 4 • Bidirectional • 1-bit windowing protocol (only 1 bit ack) • More efficient && symmetric • Original implementation has 12 processes: my ugly version weans this down to 6 – and still does not make it through.

19. Notes on Protocol 4 • I tried using various forms of compression, but never got a full search  • On the other hand, between my 5 implementations of protocol 4, SPIN caught a lot of errors.

20. 3 More Protocols? • There are three more data link protocols in Tannenbaum’s book. First n-bit windowing, then 1-bit sliding window, and finally the n-bit sliding window protocol • Since Protocol 4 did not go through, …

21. Spin v. ACL2 • ACL2 proof would work at a lower level: • + ACL2 can handle more states • - if the user can do the proof • + SPIN has a better simulator: it’s tough to simulate this type of ACL2 code. (defun next_system_state (i system_state) (cond ((== i 0) (execute_A system_state)) (t (execute_B system_state)))) ... (thm (and (not (get-val ‘bad_network_packet (init_state))) (implies (not (get-val ‘bad_network_packet s)) (not (get-val ‘bad_network_packet (next_system_state i s))))

22. Conclusions • Model-checking complex protocols is hard • SPIN is very good at helping users find bugs. The interactive simulator is useful. • Try combining SPIN with theorem proving

23. Future Work • Simplify the spec: Is there something simpler that will still distinguish ordering? • Simplify the model: 6 processes are not really necessary. • Implement a better timer • Prove the network protocols in ACL2 or PVS for comparison