Lecture 10: Protocol Design Prof. Shervin Shirmohammadi SITE, University of Ottawa Fall 2005 CEG 4183 10-1
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-2
Protocol Development Steps Application analysis Requirements Design Simulation Implementation Testing Fall 2005 CEG 4183 10-3
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-4
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-5
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 multipoint 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-6
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-7
Application-Layer PDU Protocol Data Unit control bit key update object ID Stream number sequence number application payload (update message) Application Layer Header for Protocol X UDP header X header message Transport Layer IP header UDP header X header message Networking Layer Fall 2005 CEG 4183 10-8
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: C B = ; C based on MTU and RTT Loss _ rate Not possible in all cases (such as real-time data with natural bit rate). Fall 2005 CEG 4183 10-9
Describes the logical operation of the protocol which events trigger which actions Protocol State Machine Fall 2005 CEG 4183 10-10
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-11
Simulation Node configuration Application data generation Fall 2005 CEG 4183 10-12
Simulation ( ) Fall 2005 CEG 4183 10-13
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-14
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-15
Protocol Design Example Multiplayer 3D shoot em up game. Picture courtesy of Valve Corp. Fall 2005 CEG 4183 10-16
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-17
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-18
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 Header Key Object ID Time Stamp Data Key: 1 bit ObjectID: 16 bits (>65000 simultaneous objects supported) TimeStamp: 32 bit integer, starting from January 1 st 1970 Data: X, Y, Z (16-bit integers for position) and R1, R2 (16-bit floats for orientation) Fall 2005 CEG 4183 10-19
Differential Updates Regular update messages (12245, 156, -1233) (12243, 155, -1230) (12241, 153, -1229) Differential update messages (12245, 156, -1233) (-2, -1, 3) (-4, -3, 4) regular and differential update messages Key Update Diff. Update Diff. Update... Key Update Diff. Update... Key Update a stream of update messages Differential updates save bandwidth. Key updates require reliability. Fall 2005 CEG 4183 10-20
Design Issues Many non-trivial complications: Discard any late-arriving update? What about key updates? 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-21
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 Fall 2005 CEG 4183 10-22