ng engines heavily dependent on overcomplex and expensive memory (S-RAM and CAM). Decisions on software/hardware partitioning self-evidently have to be based on the re- quirements and characteristics of the traffic being processed. As traffic becomes increasingly asynchronous it becomes progressively harder to control buffer delay and buffer-delay variabil- ity. However, it's not just 'burstiness' that needs to be considered when deciding on network processor performance. 17.7.2 Longer Sessions First, let's consider the impact of longer sessions. Sessions are getting longer partly because file sizes are getting bigger but also because sessions are becoming more complex. Multimedia sessions tend to last longer than voice calls, multiuser sessions tend to last longer than one-to- one conversations and conversational exchanges last longer than best-effort exchanges. As session lengths increase it becomes more economic to switch in hardware or, put another way, you don't need lots of software instructions to switch a long session - it's a relatively simple and deterministic transaction. 17.7.3 Shorter Packets with a Fixed Rather than Variable Length Packet size is reducing over time. This is because multimedia components are source coded using periodic sampling - typically 20 milliseconds for voice (the syllabic rate). Video sampling rates depend on the frame rate and source coding used but generally you will end up with a MAC layer that produces a stream of fixed-length packets of typically 40 bytes. The decision to use fixed rather than variable-length packets is driven by the need to get multiplexing efficiency even when the data rates coming from multiple sources can be widely different (video encoding is moving increasingly towards variable rate). It is obviously absurd to take a 40-byte payload and add a 40-byte IPv6 header to each packet, SO the idea of treating each packet as an individual entity in a multimedia network is no longer valid. As we move towards short, fixed-length packets it makes sense to hardw