lecture 10: protocol design - school of electrical … · · 2005-10-23fall 2005 ceg 4183 10-1...
TRANSCRIPT
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-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