220 likes | 331 Views
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.
E N D
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/
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
Experiment Setup • UNICAST (1-to-1) • UNICAST(1-to-N) Koyabe@erg.abdn.ac.uk
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
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
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
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
Coping with Packet Loss & Duplicates - Error-Recovery Koyabe@erg.abdn.ac.uk
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
Where does Real Loss occur ? • View at the Client Koyabe@erg.abdn.ac.uk
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
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
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
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
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
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
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
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
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
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
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
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