Fall 2005 CEG 4183 10-1

Lecture 10:

Protocol Design

Prof. Shervin Shirmohammadi

SITE, University of Ottawa

Fall 2005 CEG 4183 10-2

Introduction

• TCP and UDP are generic protocols:

– They fulfill the needs of a wide range of applications (FTP,

Telnet, SMTP, HTTP, …)

– They don’t fulfill the need of all applications (Real-time data

transfer, groupware, CVE, …)

• There’s a need for specific (non-generic) protocol:

– RTP: specific to real-time data

• Note: it uses UDP for its multiplexing capability

– Application-specific protocols usually use UDP as the

transport layer (for deployment convenience) and do their

processing at the application layer. This is known as

application-level framing.

Fall 2005 CEG 4183 10-3

Protocol Development Steps

• Application analysis

• Requirements

• Design

• Simulation

• Implementation

• Testing

Fall 2005 CEG 4183 10-4

Analysis

• How do actions in the application relate to

data generation?

• Semantics: What is the meaning of the data

generated?

• What type of data does the application

generate (syntax)? Text, integers, bytes, or

combination.

• How often does it generate the data?

Fall 2005 CEG 4183 10-5

Requirements

• What requirements does the application data have for:

– delay

– bandwidth

– reliability

– fragmentation

– …

• These are application-specific.

• They might not be uniform for all data generated by

the same application: some portions of the data might

have different requirements from other portions.

Fall 2005 CEG 4183 10-6

Design

• Based on the analysis and requirements, a protocol can be designed that addresses the discovered needs.

• Two main design considerations:

– Delivery mechanism:• How to transport messages across the network as to satisfy the delivery requirements (delay, bandwidth, reliability, …)

• If using application-level framing, you can assume UDP will do the basic delivery from one host to another (or others, in the case of multi-point communications). You can then build your delivery mechanism on top of UDP.

– Message format and exchange rules:• Protocol Message Types

• Header Syntax and Semantics

– Syntax: pattern of formation

– Semantics: meaning

• Exchange rules: the sequence of sending and responding to messages

Fall 2005 CEG 4183 10-7

Protocol Message Types

• Open image

• Annotate

• Send text

OPEN file URL

DRAW Color X0 Y0 X1 Y1

CHAT User message

• In this example we

only have one token

for each Message.

This token is

essentially the only

field in the header.

• In most

applications, there is

a need for more than

one field in the

header.

Fall 2005 CEG 4183 10-8

Protocol Data Unit

application payload

(update message)

control

bit

key

update

Stream

number

object

ID

sequence

number

Header for Protocol X

UDP

header

X

headermessage

UDP

header

X

headermessage

IP

header

Application

Layer

Transport

Layer

Networking

Layer

Application-Layer PDU

Fall 2005 CEG 4183 10-9

TCP-friendliness

• TCP-friendliness is an important design consideration.

• TCP backs off in the face of congestion, so a greedy

non-TCP protocol can choke TCP by aggressively

sending data.

• Non-TCP protocols should not violate bandwidth B

given by:

B = ; C based on MTU and RTT

• Not possible in all cases (such as real-time data with

natural bit rate).

rateLoss

C

_

Fall 2005 CEG 4183 10-10

Protocol State Machine

• Describes the

logical operation of

the protocol

– which events

trigger which

actions

Fall 2005 CEG 4183 10-11

Theoretical Analysis and Simulation

• The protocol can be theoretically analyzed, using queuing analysis

for example.

• Sometimes it is very difficult to mathematically model a protocol.

• In any case, Simulation helps identify weaknesses or design flaws

before implementing the protocol in the real world.

• Simulation must be done for an environment where the protocol will

be deployed (as realistic as possible).

• Other protocols present in that environment should be present in the

simulation as well, in order to see performance results for both those

protocols and the newly-designed protocol.

– How does my protocol behave in the presence of existing Internet

traffic? We need to simulate Internet traffic (see queuing analysis

lecture).

Fall 2005 CEG 4183 10-12

Simulation

Node configuration

Application data generation

Fall 2005 CEG 4183 10-13

Simulation (…)

Fall 2005 CEG 4183 10-14

Prototyping and Testing

• After modifying the design based on simulation results, a prototype should be developed to test the protocol in the real world.

• The prototype should initially implement only architecturally-significant parts of the design.

– No need to implement all features yet

• The prototype should be tested and inefficiencies/problems should be addressed

– Design level problems

– Implementation problems

Fall 2005 CEG 4183 10-15

Implementation and Deployment

• After successful testing, remaining features can be added to have a complete implementation.

• Implementation is usually done as an application-layer protocol (even though it’s designed as end-to-end) using UDP

– a.k.a. Application-level Framing

• For something to be really done in the transport layer (such as UDP and TCP) we need kernel access and wide deployment.

– even a widely-used protocol such as RTP is not in most kernels, yet.

Fall 2005 CEG 4183 10-16

Protocol Design Example• Multiplayer 3D “shoot ‘em up” game.

Picture courtesy of Valve Corp.

Fall 2005 CEG 4183 10-17

Analysis

• Data is generated from players running, objects moving,

weapons being fired, buildings destroyed, …

• Most objects (humans, aliens, …) move constantly and

undeterministically. They produce lots of update

messages on a constant basis. (Type 1)

• Some objects (tanks, airplanes) move constantly but in

a more deterministic fashion based on velocity (speed

and direction). We can send updates only when there’s

a change in direction or speed. (Type 2)

• Some actions, such as a weapon firing or a building

destroyed, send one message only (e.g., location and

direction of firing). (Type 3)

Fall 2005 CEG 4183 10-18

Requirements

• Minimize delay!

– Performance evaluations have shown the ideally, end-to-end delay should be less than 100-200 msec for smooth playing.

• Type 1 messages don’t require reliability since they are corrected by the next update.

– Need to be careful not to send too many updates because bandwidth is limited.

• Type 2 messages don’t require reliability if sent often enough; otherwise require reliability.

• Type 3 messages require reliability.

• All 3 types are one-to-many transmissions (point to multipoint).

Fall 2005 CEG 4183 10-19

Design

• Use UDP multicast– Other choices possible for specific circumstances

• Need to indicate key updates, which require reliability.

• Need to know what object has changed state (Object ID must be globally unique within the environment)

• Need to discard late packets.

• An example Protocol Message Type:

Update_Type1

Key: 1 bit

ObjectID: 16 bits (>65000 simultaneous objects supported)

TimeStamp: 32 bit integer, starting from January 1st 1970

Data: X, Y, Z (16-bit integers for position) and R1, R2 (16-bit floats for orientation)

KeyObject

ID

Time

StampData

Header

Fall 2005 CEG 4183 10-20

Differential Updates

(12243, 155, -1230) (12241, 153, -1229)(12245, 156, -1233)

(-2, -1, 3)(12245, 156, -1233) (-4, -3, 4)

Regular update messages

Differential update messages

Diff. UpdateKey Update . . . Key UpdateDiff. Update . . . Key Update Diff. Update

regular and differential update messages

a stream of update messages

• Differential updates save bandwidth.

• Key updates require reliability.

Fall 2005 CEG 4183 10-21

Design Issues

• Many non-trivial complications:

– Discard any late-arriving update? What about keyupdates?

• Only if their timestamp indicates this is older than a previously received key update for that object.

– Reliability based on ACK or NACK? Big topic!

• ACK creates more traffic than NACK, but is needed in cases where the object doesn’t move for a long time.

• Definitely ACK for message type 3.

– How to implement ACK or NACK for a large group size? Should everyone send ACK (floods the network)?

• Use a representative-based approach

Fall 2005 CEG 4183 10-22

Implementations

• Many implementations for such environments; both for games and for simulations.

• Distributed Interactive Simulation (DIS) is an IEEE standard for such environments.

– Practically used for army combat training and simulations.

• In practice, Multicast is only used for LANs. Games use other means to support home users:

– Server farms

– Upcoming: Peer-to-peer (P2P) techniques