1 / 22

Timeline System Performance & Experience MPEG-2 File Delivery to Foresterhill over ATM/IP

Timeline System Performance & Experience MPEG-2 File Delivery to Foresterhill over ATM/IP. Presentation by Martin L.W.D Koyabe Electronics Research Group e-mail: koyabe@erg.abdn.ac.uk http://www.erg.abdn.ac.uk/. Aims of Experiment.

jovita
Download Presentation

Timeline System Performance & Experience MPEG-2 File Delivery to Foresterhill over ATM/IP

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. Timeline System Performance & ExperienceMPEG-2 File Delivery to Foresterhill over ATM/IP Presentation by Martin L.W.D Koyabe Electronics Research Group e-mail: koyabe@erg.abdn.ac.uk http://www.erg.abdn.ac.uk/

  2. Aims of Experiment • Examine the performance of Timeline: - Different Network topologies - Different Bandwidth - Different Operating System (OS) platforms • Evaluate the pattern of loss: - Spartial Loss - Correlated Loss • Investigate the suitability of Timeline in delivering files (MPEG2 - 2Mbps ) to Foresterhill Medical School Library:- Is it suitable ? (Yes/No) • Assess the limitations and possible improvements. Koyabe@erg.abdn.ac.uk

  3. Experiment Setup • UNICAST (1-to-1) • UNICAST(1-to-N) Koyabe@erg.abdn.ac.uk

  4. Timeline: Overview • Timeline service is provided by two protocols:- Session Protocol: co-ordinates transfer of data.- Transfer Protocol: transfers the video clip from server to client. • Both Session and Transfer protocols are located on common server platform. • Transfer protocol has three design objectives:- the server is not concerned with number or location of clients.- clients may start or stop transfers at any time.- caching of parts of video clip (blocks) may be performed by either clients or independent repair agents. Koyabe@erg.abdn.ac.uk

  5. Data Transfer & Protocol Operation • Transfer protocol is receiver based - Shown to achieve high performance [Yamamoto et al]. • Client registers interest in files it wishes to receive. Session server accepts file request/s and triggers transfer server to send file. • Announcements are transmitted using well-known announcement address. The packet contains details of transfer (File name, context, size, rate etc). • Once initiated, server starts file transmission as sequence of blocks. Koyabe@erg.abdn.ac.uk

  6. Reliability • Reliability in UNICAST implies sender gains knowledge of the state of receivers. • Timeline’s reliability is based on congestion control, timers and error recovery algorithms. • Congestion control - not reactive (doesn’t reduce bandwidth with detection of congestion), instead uses a rate control algorithm to regulate flow of data from server. • Initial peak bit-rate is set at the start of the transmission, this may in future make use of the bandwidth reservation service being introduced - RSVP. • Random timer - used for RTO, minimizing NACK implosion at the sender • Error Recovery - is decisional - receivers decide how to receive the lost portion of data compared to statistical - using redundant data to recover from loss i.e FEC [Montgomery et al]. Koyabe@erg.abdn.ac.uk

  7. Coping with Packet Loss & Duplicates - Error-Recovery • Timeline provides complete ordered data delivery at file level. • In UNICAST duplicates - imply erroneous transmission or excessive delay along the network. • Delayed announcements, low transmission rates reduce duplicate packets but achieves low throughput. • Low transmission rates, optimum client memory buffer-size and RTO (<RTT) achieves Lossless transmission. Koyabe@erg.abdn.ac.uk

  8. Coping with Packet Loss & Duplicates - Error-Recovery Koyabe@erg.abdn.ac.uk

  9. Where does Real Loss occur ? • Server announces the max_offset (announced HWM) sequence number to the receiver. • Loss seen before announce HWM sequence number constitutes “True” Loss. • Loss seen after the announced HWM sequence number would either be Loss due to delay or “True” Loss. • LWM sequence number marks the completely ACKed packets seen by the receiver. • Any delay at the sender to transmit announcement, will counter delay the receiver to retransmit NACKs. • Receiver checks for “True” Loss and advances the LWM to announced HWM. Koyabe@erg.abdn.ac.uk

  10. Where does Real Loss occur ? • View at the Client Koyabe@erg.abdn.ac.uk

  11. Performance & Loss Pattern • Throughput (T) = ((No_of_MSs X MSS X 8.0)/t)Where: No_of_MSs - Number of successively transmitted packetsMSS - Packet size (1400 Bytes < MTU)t - Total time taken to transfer file (seconds) • Peak Bit-Rate - Selected upper limit transmission rate from server. • Loss Rate (L) = (Lost_pkt_count)/(No_of_MSs)Where: No_of_MSs - Number of successively transmitted packetsLost_pkt_count - Total number of Packets lost • % Loss Rate = (LX100) • Burst Length (n) - Number of consecutively lost packets • Long Loss Burst - Bursts that affect 100 or more consecutive packets Koyabe@erg.abdn.ac.uk

  12. Throughput & Loss (1-to-1 UNICAST) • 100Mbps/Switch/100Mbps - UNIX[Server]-to-UNIX[Client] (Full/Full-Duplex) • At 10 Mbps - approx 5.7 Mbps Throughput writing to disk. • At 35 Mbps - approx 7.4 Mbps Throughput without writing to disk. • Reason: Burst Loss • 100Mbps/Switch/100Mbps - UNIX[server]-to-WinNT[client] (Full/Full-Duplex) • At 90 Mbps - approx 2.6 Mbps Throughput writing to disk. • At 10 Mbps - approx 3.0 Mbps Throughput without writing to disk. • Reason: Burst Loss/Disk I/O Seek Koyabe@erg.abdn.ac.uk

  13. Throughput & Loss (1-to-1 UNICAST) • 155Mbps/Switch/10Mbps - UNIX[Server]-to-WinNT[Client] (Full/Half-Duplex) at Foresterhill Medical School Library • At 8 Mbps - approx 4.2 Mbps Throughput writing to disk. • At 35 Mbps - approx 7.4 Mbps Throughput without writing to disk. • Reason: Burst loss/Disk I/O Seek • Higher frequency for short burst length (n = 1-3). Koyabe@erg.abdn.ac.uk

  14. Throughput & Loss (1-to-1 UNICAST) • 155Mbps/Switch/10Mbps - UNIX[Server]-to-WinNT[Client] (Full/Half-Duplex) at Foresterhill Medical School Library Koyabe@erg.abdn.ac.uk

  15. Throughput & Loss (1-to-N UNICAST) • 155Mbps/Switch/10Mbps - UNIX[Server]-to-WinNT[Client] (Full/Half-Duplex) at Foresterhill Medical School Library • At 12 Mbps - approx 2-3 Mbps Throughput both writing and without writing to disk. • Reason: Server overload/Burst loss/ Disk I/O Seek • Higher frequency for short burst length (n = 1-3). • Clients experienced long burst lengths (n = 17). Koyabe@erg.abdn.ac.uk

  16. Throughput & Loss (1-to-N UNICAST) • 155Mbps/Switch/10Mbps - UNIX[Server]-to-WinNT[Client] (Full/Half-Duplex) at Foresterhill Medical School Library Koyabe@erg.abdn.ac.uk

  17. Throughput & Loss (1-to-N UNICAST) • 155Mbps/Switch/10Mbps - UNIX[Server]-to-WinNT[Client] (Full/Half-Duplex) at Foresterhill Medical School Library Koyabe@erg.abdn.ac.uk

  18. Throughput & Loss (1-to-N UNICAST) • 155Mbps/Switch/10Mbps - UNIX[Server]-to-WinNT[Client] (Full/Half-Duplex) at Foresterhill Medical School Library Koyabe@erg.abdn.ac.uk

  19. Throughput & Loss (1-to-N UNICAST) • 155Mbps/Switch/10Mbps - UNIX[Server]-to-WinNT[Client] (Full/Half-Duplex) at Foresterhill Medical School Library Koyabe@erg.abdn.ac.uk

  20. Limitations • Sockets - many socket sessions led to packets being misordered. Further tests showed that misordering reduces throughput when writing to disk . Results [without misordering - 35Mbps/misordering - 15Mbps for 14000Byte File @ Steps of 5] • Disk I/O seeks & overload - WinNT doesn’t have a disk-sequencing cache to ensure data is written in optimal order. Therefore most client/s were overwhelmed by server transmissions - dropping packets at high peak bit-rates. Results [shown earlier High-UNIX/ Low-WinNT]. • WinNT OS - background traffic from WinNT clients led to low throughput due to, packet collision, misordering and jitter effect at client LAN (NIC-SWITCH). Result [yet to be quantified] • Network Layout - Half-duplex transmission from switch to clients (NIC-SWITCH) limits the maximum throughput attainable. Results show [Full-Duplex transmission: 100/10 2.9 Mbps] • Foresterhill ATM network emulator does not support multicasting which would have been appropriate for efficient utilization of Bandwidth and Scalability. Koyabe@erg.abdn.ac.uk

  21. Conclusions • Timeline can offer reliable 1-to-1 UNICAST transmission at file level at different bandwidth, OS platforms and Network layouts. • Most of Loss seen was correlated at receiver end and minimal along the network. • There was predominance solitary Loss (high frequency for short burst length) forming a skewed distribution of burst length at the receiver. • Yes ! Timeline is suitable for delivering MPEG-2 files to Foresterhill Medical School at higher throughput (> 2 Mbps). Koyabe@erg.abdn.ac.uk

  22. Further Research • Further performance test to be done at application level (interface currently being developed). • Evaluate performance of Timeline with different Network topologies (run trials in Manchester and London). • Comparison of Timeline with other protocols (SRM, TMTP, RMDP etc) and products (StarBurst, Wb, WebCasting, Mbone, Vic etc). • Adopt efficient and accurate multicast algorithms for: Error-Recovery (i.e FEC), Timers, Caching and scalability while avoiding “one size fits all” problem. Koyabe@erg.abdn.ac.uk

More Related