Network Latency, Jitter and Loss Packet 1 Packet
78 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games 1500 bytes long and had begun transmission just before packet 5 arrived, no amount of preferential queuing at the packet level could avoid packet 5 having to wait until packet 1 is transmitted. A partial solution to this scenario is offered by link layer technologies capable of concurrently interleaving multiple IP packets during transmission. For example, most consumer ADSL services actually run ATM over the ADSL physical layer, and then implement their packet service over a single ATM virtual channel [TR017, ARM2000]. However, in principle, the ADSL modem could utilise two or more parallel virtual channels upstream towards the ISP, and send different streams of cells on each virtual channel [I311]. Game packets and normal packets would be segmented onto distinct virtual channels and their constituent cells interleaved in time according to the packet s priority. Recall that ATM cells are only 53 bytes long (carrying 48 bytes of payload and 5 bytes of header). Thus, the serialisation delay experienced by a game packet drops down to the time it would take to send an ATM cell belonging to the normal packet already in flight. It is as though the police car could cut the truck in half. Unfortunately, ATM over ADSL is not used in this manner as of the time of writing, although it remains a distinct possibility as ISPs grapple with offering the best control of jitter and latency on the upstream side of consumer broadband links. Similar approaches are theoretically possible with Multi-Class Multi-Link (MCML) and Real-Time Framing (RTF) PPP over serial links [RFC2686, RFC2687] and segmenting packets across minislots in DOCSIS-based cable modem systems [DOCSIS]. Further discussion of such schemes is beyond the scope of this book. 5.3.3 Where to Place and Trust Traffic Classification Much of the classification, queuing and scheduling techniques discussed so far are practical with today s technology. The major stumbling block faced by ISPs today actually revolves around how they know, for certain, what packets to give priority to at any given time. (Or, in the terminology of this chapter, which packets are game traffic deserving preferential treatment.) Conversely, how does the ISP ensure that only authorised traffic gets preferential treatment? Only a game client and game server know for sure what IP packets constitute game traffic. The ISP wishing to provide preferential service must configure their routers with the 5-tuple rules or DSCP values that identify packets deserving preferential treatment. But how does the ISP initially discover the right 5-tuple or DSCP values? Ask the game clients for 5-tuple values? Trust the game clients to set the DSCP to a well-known value? In general, ISPs should not trust an outside entity (which includes hosts it does not control) to set the DSCP value appropriately. If it becomes well known that DSCP == 1 results in priority traffic handling, every application on every host will naturally be inclined to set DSCP to one on their outbound packets. We would be right back at the beginning of the problem, with everyone s packets classified into the game traffic queue. Thus the assignment of DSCP values must be performed by routers the ISP trusts, typically at the edges of the ISP s network. DSCP assignment will occur after 5-tuple classification by the ISP s router. This begs an obvious question how does the ISP s router know which 5-tuples represent game traffic? If an ISP hosts its own game server, then it knows one side of the 5-tuple the IP address and port number of the game server. This information may well be sufficient to
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services