1 / 20

Pål Halvorsen, Thomas Plagemann, and Vera Goebel Institute for Informatics, University of Oslo

How to Minimize Transport Protocol Processing: Implementation and Evaluation of Network Level Framing. Pål Halvorsen, Thomas Plagemann, and Vera Goebel Institute for Informatics, University of Oslo Norway.

reed
Download Presentation

Pål Halvorsen, Thomas Plagemann, and Vera Goebel Institute for Informatics, University of Oslo

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. How to Minimize Transport Protocol Processing:Implementation and Evaluation of Network Level Framing Pål Halvorsen, Thomas Plagemann, and Vera Goebel Institute for Informatics, University of Oslo Norway 4th International Workshop on Multimedia Network Systems and Applications (MNSA ’02),Vienna, Austria, July 2002

  2. Overview • Application scenario • The INSTANCE project • Network Level Framing (NLF) • design and implementation • performance evaluation • Summary and conclusions

  3. Application Scenario Media-on-Demand server: Applicable in applications like News- or Video-on-Demand provided by city-wide cable or pay-per-view companies Multimedia Storage Server Network Network • Retrieval is the bottleneck:Some important factors: • Memory management • Communication protocol processing • Error management • Project goals:Optimize performance within a single server: • Reduce resource requirements • Maximize number of clients

  4. Project goals:Optimize performance within a single server: • Reduce resource requirements • Maximize number of clients The INSTANCE Project • We try to make optimal use of agiven set of resources: • memory architecture • integrated error management • network level framing (NLF)

  5. Traditional Approach Upload to server Frequency: low (1) Download from server Frequency: very high

  6. TRANSPORT TRANSPORT Network Level Framing (NLF): Basic Idea TRANSPORT TRANSPORT Upload to server Frequency: low (1) Download from server Frequency: very high

  7. When to Store Packets

  8. udp_PreOut() udp_output() Prepend UDP and IP headers Temporarilyconnect udp_output() Prepare pseudo header for checksum, clear unknown fields Prepend UDP and IP headers Precalculate checksum Prepare pseudo header for checksum Calculate checksum udp_QuickOut() Update UDP and IP headers Fill in some other IP header fields Update checksum, i.e., only add checksum of prior unknown fields Hand over datagram to IP Fill in other IP header fields Hand over datagram to IP Disconnectconnectsocket Splitting the UDP Protocol UDP UDP UDP

  9. Traditional Checksum Operations – I • The UDP checksum covers three fields: • A 12 byte pseudo header containg fields from the IP header • The 8 byte UDP header • The UDP data (payload) • Simplified checksum calculation function (in_cksum): u_16int_t *w; int checksum; for each mbuf in packet { w = mbuf -> m_data; while data in mbuf { checksum += w; w++; } }

  10. Traditional Checksum Operations – II • Traditional checksum operation: u_16int_t *w; int checksum; for each mbuf in packet { w = mbuf -> m_data; while data in mbuf { checksum += w; w++; } }

  11. + + = Modified Checksum Operations • NLF checksum operation:

  12. data precalculated header (meta-data) Implementation – I • Straight forward implementation: • To allow flexibility, we have one data and one meta-data file: data meta-data UDP

  13. Implementation – II • NLF version 1: • most of the UDP/IP processing is spent on checksum calculation • precalculate checksum over data payload • during transmission time: • generate header • calculate checksum over header and add precalculated payload checksum • NLF version 2: • several reports show increased performance using header templates • precalculate checksum over data payload • during stream open: • generate header template • calculate header checksum • during transmission time: • block copy header template • add header template checksum, payload checksum, and packet length field

  14. Performance: Test Setup • Implemented in NetBSD 1.5.2 • Dell Precision Workstation 620 • PIII 933 MHz CPU • 3 COM 1 Gbps NIC • Software probe • RDTSC instruction • CPUID instruction • probe overhead 206 cycles • Performed tests using 1 KB, 2 KB, 4 KB, and 8 KB UDP packets • Transmitting 225 MB of data • Data is transmitted using the zero-copy data path

  15. ~ 50 cycles less Performance: Checksum Overhead increases linearly with payload size 11899 23674 CPU cycles Overhead is constant regardless of payload Packet size

  16. ~25 cycles more Performance: Header Overhead CPU cycles Packet size NLF version 3: use header template checksum, but generate header instead of block copy

  17. Performance: UDP 12304 24108 CPU cycles Packet size

  18. Conclusions and Future Work • Network Level Framing reduces communication system processing by precalculating • payload checksum (off-line) • header checksum (stream open) • Gain per packet is dependent of packet payload size, e.g., 1 KB (8 KB)  97.3 % (99.6 %) Our mechanisms (at least) double the number of concurrent clients • Ongoing and future work: • NLF in lower protocols (ongoing) • On-board processing

  19. Questions??

  20. Related Work • Checksum caching in memory • high data rates  cached elements will be removed before it can be reused • Header templates • block-copying is time consuming • On-Board processing • useful and becoming “off-the-shelve” hardware • may be nice to combine with NLF

More Related