Network Protocol Design and Evaluation 01 - Introduction Stefan - - PowerPoint PPT Presentation

▶
network protocol design and evaluation
SMART_READER_LITE
LIVE PREVIEW

Network Protocol Design and Evaluation 01 - Introduction Stefan - - PowerPoint PPT Presentation

Dec 03, 2023 475 likes •889 views

Network Protocol Design and Evaluation 01 - Introduction Stefan Rhrup University of Freiburg Computer Networks and Telematics Summer 2009 Organization Schedule Lecture: Wednesday 9-11 and Friday 11-12 Exercise: Friday

slide-1
SLIDE 1

University of Freiburg Computer Networks and Telematics Summer 2009

Network Protocol Design and Evaluation

01 - Introduction

Stefan Rührup

slide-2
SLIDE 2

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Organization

  • Schedule
  • Lecture: Wednesday 9-11 and Friday 11-12
  • Exercise: Friday 12-13
  • Requirements
  • no formal requirements
  • basic knowledge of network protocols, programming

and software engineering

2

slide-3
SLIDE 3

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Contents

  • Protocol design principles
  • Modeling and specification
  • Simulation of network protocols
  • Performance evaluation
  • Formal analysis

3

slide-4
SLIDE 4

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Material

  • Slides will be available as PDF on the course website

http://cone.informatik.uni-freiburg.de/teaching/lecture/protocol-design-s09/

  • More material (book chapters, research papers) related to

special topics will be announced in the lecture

  • Books

There are lots of books on computer networking and

  • protocols. Most of them focus on the architectures and

algorithms, not so much on design aspects.

4

slide-5
SLIDE 5

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Books ...

  • James F. Kurose, Keith W. Ross:

Computer Networking - A Top-Down Approach, 4/e, 2007, ISBN 0-321-49770-8

  • Overview of computer networks,

Internet protocols, from link layer to application layer.

5

slide-6
SLIDE 6
  • Gerard J. Holzmann:

Design and Validation of Computer Protocols, Prentice Hall, 1991, ISBN 0-13-539834-7

  • Design principles of communication

protocols, formal specification and validation

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Books ...

6

slide-7
SLIDE 7

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Books ...

  • S. Keshav:

An Engineering Approach to Computer Networking, Addison Wesley, 1997,

ISBN 0201634422

  • Overview of communication protocols,

explains design decisions

7

slide-8
SLIDE 8

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Related lectures and courses

  • Systeme II

(highly recommended for this lecture)

  • Communication Systems
  • Special lectures: Ad hoc networks, Wireless Sensor

Networks, P2P Networks

  • Lab course/Bachelor Projects:

Wireless Sensor Networks

8

slide-9
SLIDE 9

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

In this introduction...

  • What is a protocol?
  • Protocol design and what it is good for
  • Examples for protocol design
  • Basic elements of a protocol

9

slide-10
SLIDE 10

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Motivation

  • Statement: Network protocols are standardized, they

are tested and ready to use.

  • Why Protocol Design?
  • New demands by advances in communication

technology

  • More distributed, net-based, and mobile applications
  • Customization, cross-layer optimization etc.
  • Important part of the design of distributed systems

10

slide-11
SLIDE 11

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Motivation (2)

  • ...and why protocol evaluation?
  • Testing and (problem) analysis
  • for new protocols
  • if standard protocols are used in new contexts

(e.g. Internet protocols in wireless networks)

  • if protocols of different layers are combined
  • if protocols share resources

11

slide-12
SLIDE 12

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

What is a protocol?

12

  • Human protocol:
  • “I have a question”
  • “What’s the time?”
  • … specific msgs sent
  • … specific actions taken

when msgs received,

  • r other events

Hi Hi

Got the time?

9:30

time

slide-13
SLIDE 13

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

What is a protocol? (2)

13

Hi Hi

Got the time?

9:30

time

Human protocol Computer network protocol TCP connection request TCP connection response

HTTP GET

File

slide-14
SLIDE 14

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

What is a protocol? (3)

  • High level definition (Holzmann 1991):

Agreement on information exchange in distributed networking

  • A protocol defines...
  • format for valid messages (syntax)
  • rules for data exchange (grammar)
  • a vocabulary of messages and their meaning (semantics)

... similar to a language (a refined definition will follow later)

14

slide-15
SLIDE 15

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

What is a protocol? (4)

15

  • Low-level abstraction: A state machine
  • The protocol state defines which actions are performed

and how to respond to events

  • A communicating state machine consists of
  • set of states
  • state transitions
  • message queues
  • utput

states & transitions input message queues

slide-16
SLIDE 16

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

What is protocol design?

  • It’s more than just implementation
  • A development process:
  • Requirements
  • Specification and validation
  • Implementation
  • Test and evaluation
  • ...a challenging task, even for simple protocols

16

slide-17
SLIDE 17
  • The Clayton Tunnel accident: rail crash in Clayton, West

Sussex, UK in 1861 due to a false signal

  • Example for a failure of a simple communication protocol
  • 21 dead, 176 injured

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Bad protocol design or human failure?

17

slide-18
SLIDE 18

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

The setting

18 signalman signalman telegraph line semaphore 2 tracks tele- graph semaphore tele- graph

  • A semaphore blocks automatically once a train passes.
  • It is reset by a signalman, if the other signalman reports that the train left the tunnel

train in tunnel train in tunnel? tunnel clear 3 codes/messages:

slide-19
SLIDE 19

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

The protocol

19 tunnel train in tunnel train tunnel tunnel clear train set reset train in tunnel

slide-20
SLIDE 20

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

The protocol (2)

  • The protocol should ensure that only one train per track is

in the tunnel

  • In case of a semaphore malfunction the signalmen are

notified and use their flags

  • The third message (“train in tunnel?”) is optional and can

be used to request a message again Is this protocol reliable?

20

slide-21
SLIDE 21

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

The accident (1)

21 tunnel train in tunnel 1st train not set (malfunction) 2nd train 2nd train 1st train train in tunnel train in tunnel (2nd message) 2nd train gets red flag, brakes, and stops in the tunnel

slide-22
SLIDE 22

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

The accident (2)

22 3rd train 2nd train 1st train train in tunnel train in tunnel (stopped) 1st train train in tunnel train in tunnel 2nd train 3rd train (stopped) Is the 2nd train already

  • ut?

train in tunnel? (stopped) (stopped)

slide-23
SLIDE 23

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

The accident (3)

23 3rd train 2nd train 1st train (stopped) train in tunnel? 1st train 2nd train 3rd train go! (stopped) tunnel clear train is out time to back out of the tunnel

slide-24
SLIDE 24

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Who is to blame?

  • The driver of the second train? ...but he followed the signal.
  • Signalman A, who misinterpreted the “tunnel clear” message?

... but how could he know which train was meant?

  • Signalman B, who did not react on two “train in tunnel” msgs.?

... but this was not specified!

24 1st train train in tunnel train in tunnel 2nd train 3rd train train in tunnel? tunnel clear

A B

slide-25
SLIDE 25

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Conclusion

  • The signalmen did not have the appropriate set of

messages

  • An unexpected case occurred that could not be handled

by the protocol.

  • The protocol could not recover from an error,

it was incomplete in this sense

25

slide-26
SLIDE 26

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Lessons learned

  • Consider that errors might occur (expect the unexpected)
  • Allow to handle unexpected errors
  • Check whether unnecessary or invalid assumptions are

made

26

slide-27
SLIDE 27

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

The problem of protocol design

  • How to find the appropriate rules for communication

that are minimal, logically consistent, complete, and efficient? ... difficult.

  • First, we begin with a thorough specification of the rules,

the messages and assumptions about the environment, ... all elements of the protocol

27

slide-28
SLIDE 28

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Five elements of a protocol

Elements of a protocol specification (Holzmann 1997): 1. The service to be provided by the protocol 2. The assumptions about the environment in which the protocol is executed 3. The vocabulary of messages used to implement the protocol 4. The encoding (format) of each message in the vocabulary 5. The procedure rules guarding the consistency of message exchanges

28

slide-29
SLIDE 29

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Another example

  • Lynch’s protocol: A protocol for full-duplex alternating

data transmission protocol for a half-duplex telephone line

  • presented by W.C. Lynch as “a reasonable looking but

inadequate scheme published by one of the major computer manufacturers”

  • an example for the difficulty to design protocols

29

[W.C. Lynch: “Computer Systems: Reliable full-duplex file transmission over half-duplex telephone line”, Comm. ACM, 1968] see also [Holzmann 1991]

slide-30
SLIDE 30

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Lynch’s protocol - specification

30

  • Service: The protocol should enable reliable full-duplex

message transmission (simultaneous transmissions in both directions). A message transmission is answered by a positive or negative acknowledgement.

  • Environment:
  • Two users sharing one communication channel
  • Messages can be corrupted, but the are never lost.

Corrupted messages are detected and turned into error messages

slide-31
SLIDE 31

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Lynch’s protocol - specification

31

  • Vocabulary of messages:

Messages plus acknowledgement and error flag Vocabulary = {ACK, NACK, ERR}

  • Message format:
  • data (char)
  • ack flag (binary)

+ error flag (binary)

slide-32
SLIDE 32

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Lynch’s protocol - specification

32

  • Procedure Rules (informal):

“1. If the previous reception was error-free, the acknowledge bit of the next transmission is one; if the reception was in error the bit is zero.

  • 2. If the acknowledge bit of the previous reception was zero,
  • r the previous reception was in error, retransmit the old

message; otherwise fetch a new message for transmission.”

slide-33
SLIDE 33

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Lynch’s protocol - specification

33

  • Procedure Rules (formal):

NACK ERR get next char get next char ACK NACK ACK ACK start

[Holzmann 1991]

receive send function call

receive

state

slide-34
SLIDE 34

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Lynch’s protocol - example

34

NACK ERR get next char get next char ACK NACK ACK ACK start

Terminal A Terminal B msg error ack msg error ack a b b OK ERR OK ACK (ACK) ACK x x y OK OK OK ACK NACK ACK

error received retransmit receive

slide-35
SLIDE 35

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Specification problems

  • Design flaws:
  • Transmission in one direction does not continue

if get_next_char does not return data

  • Initiation and termination not specified

35

NACK ERR get next char receive get next char ACK NACK ACK ACK start termination?

slide-36
SLIDE 36

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Specification problems

  • An attempt to repair:
  • One-way transmission: Use filling messages,

such that get_next_char does not block

  • Initiation by sending a fake error message,

such that receive does not block

  • How to terminate after exchanging filler messages?

36

slide-37
SLIDE 37

accept char accept char

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Specification problems

  • More problems: Question when to accept a message is

left open. If a terminal accepts all error-free messages then duplicates cannot be detected.

37

NACK ERR get next char get next char ACK NACK ACK ACK start [ERR]

fake error message, sent by

  • ne of the terminals

receive

slide-38
SLIDE 38

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Specification problems

  • Example for the duplication problem:

A’s sequence: a, b, c; B’s sequence: x, y, z

38 Terminal A Terminal B msg error ack msg error ack

  • a

a [ERR] ERR OK ACK (ACK) NACK x x x OK ERR OK NACK (NACK) ACK

accept x accept x accept a ACK(x) is lost retransmit x initiate

slide-39
SLIDE 39

Network Protocol Design and Evaluation Stefan Rührup, Summer 2009 Computer Networks and Telematics University of Freiburg

Lessons learned

39

  • Design flaws are not always obvious
  • Some errors occur very rarely.

This makes it very difficult to detect a design flaw.

  • Flaws are usually difficult to fix.
  • Even simple protocols require a good design.