15
©2001 Pål Halvorsen INFOCOM 2001, Anchorage, April 2001 Integrated Error Integrated Error Management Management in MoD Services in MoD Services Pål Halvorsen, Thomas Plagemann, and Vera Goebel University of Oslo, UniK- Center for Technology at Kjeller Norway

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001 Integrated Error Management in MoD Services Pål Halvorsen, Thomas Plagemann, and Vera Goebel University

Embed Size (px)

Citation preview

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Integrated Error Management Integrated Error Management

in MoD Servicesin MoD ServicesPål Halvorsen, Thomas Plagemann, and Vera

GoebelUniversity of Oslo, UniK- Center for Technology at Kjeller

Norway

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Overview

• Application Scenario

• Integrated Error ManagementIntegrated Error Management– Basic idea– Code requirements– Possible solutions– Evaluation

• Conclusions

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Media-on-Demand server:Applicable in applications like News- or Video-on-Demand provided by city-wide cable or pay-per-view companies

Application Scenario

Network Network

Multimedia Storage Server

Project goals:Optimize performance within a single server:• Reduce resource requirements • Maximize number of clients

Retrieval is the bottleneck:Some important factors:• Memory management• Communication protocol processing• Error management

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Traditional Error Management

FEC Encoder FEC Decoder

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Integrated Error Management

FEC Encoder FEC Decoder

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Correcting Code Requirements

• Erasure (known errors) and error (unknown errors) correcting

• Decoding throughput (recovery performance)

• Amount of redundant data

• Applicable within a single file

• Cost of decoding function dependent on the corruption rate

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Possible Schemes• Error and erasure correcting codes

Bad performance (< 1.7 Mbps) Not dependent of corruption rate (< 3.5 Mbps without any corruption)

• Erasure correcting codes Adequate performance (> 6 Mbps) Corrects only erasures

• Combined schemes– Erasure correcting / Error correcting

Capable of recovering from most errors Even more redundant data Performance still a problem (< 1.7 Mbps)

– Erasure correcting / Error detection Adequate performance (> 6 Mbps) Capable of recovering from most errors (Almost) no additional redundant data

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Prototype Design

• Combination of the traditional UDP checksum and an erasure correcting code (Cauchy-based Reed-Solomon Erasure)

• Disk array with 8 disks, i.e., 7 information disks and 1 parity disk:

Write operations a la RAID level 4/5

Read operations a la RAID level 0

One codeword, contained in one or more stripes, is read as one read operation

Each striping unit consists multiple symbols each transmitted as a UDP packet

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Codeword Size and Amount of Redundancy

Requirements:• Codeword_size n stripe_size, n Z • Recover from one disk failure and (most) network errors

Our current approach:– Using a codeword of 256 symbols with 32 redundant symbols

corrects one out of 8 disks

corrects most errors in the network according to our error model, i.e., any 32 out of 256 packets

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Packet (Symbol) Sizes - I

• Correcting codethroughput suggests a largesymbol size

Lowthroughput

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

• Correcting code (startup) delay suggests a small symbol size

Packet (Symbol) Sizes - II

Lowthroughput

Highstartup delay

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Results and Observations – IExperimental Setup

• Assuming coding performance is only bottleneck

• Transmitted a 225 MB file(corresponding to a 5 minutes 6 Mbps playout)

• Used a worst-case loss scenario

• Used several different machines

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Results and Observations – IIServer Side

• No extra disk space needed

• No additional time needed to retrieve parity data

• No overhead managing retransmissions

• Increased buffer space and bandwidth requirement of 12.5% storing and transmitting redundant data.

• Encoding throughput limitation of ~3 Mbps (Intel, 166 MHz) to ~25 Mbps (Intel, 933 MHz)

is eliminated by retrieving parity data from disk

The server can support more concurrent users

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Results and Observations – IIIClient Side

• Increased buffer requirement for decoding the received data (2 MB, 3 MB, 5 MB, and 9 MB using 1 KB, 2 KB, 4 KB, and 8 KB packets, respectively)

• Additional CPU requirements recovering lost/corrupted data

• Additional (worst case) startup delay between ~0.1 s (Intel, 933 MHz) and ~4.5 s (Intel, 166 MHz)

decoding the first block can be experienced

• In-time decoding

hiccup free presentation

©2001 Pål HalvorsenINFOCOM 2001, Anchorage, April 2001

Conclusion

• The INSTANCE project aims at optimizing the data retrieval in an MoD server

• Integrated Error ManagementIntegrated Error Management

• Future work

• More information: www.unik.no/~paalh/instance