2Stream Problem Final ReportBy Heshan Lin, 02/2003

1 Model of 2 Stream Problem

1.1 Review the SloPS Methodology and Pathload Tool[1]Suppose that SND transmits a periodic packet stream to RCV. The stream consists of K packets, where K is the length of the stream. The size of each packet is L bits, while the packet transmission period is T seconds. The transmission rate of the stream is R = L/T bits per second.

SND timestamps each packet i prior to its transmission with a timestamp ti. Let ai be the arrival time of the i'th packet at RCV. Define relative One-Way Delay (OWD) as

. Upon the receipt of the entire stream, RCV inspects the sequence of relative OWDs to check whether the transmission rate R is larger than the available bandwidth A. To measure the relationships between A and R, pathload define 2 statistic metric: Pairwise Comparison Test (PCT) metric and Pairwise Difference Test (PDT) metric.The PCT metric of a stream is

,

where I(X) is one if X holds, and zero otherwise. In pathload, the PCT metric reports ‘increasing trend’ if SPCT>0.66, ‘no-increasing trend’ if SPCT<0.54, and ‘ambiguous trend’ otherwise.The PDT metric of a stream is

.

It reports ‘increasing trend’ if SPDT>0.55, ‘no-increasing trend’ if SPDT<0.45, and ‘ambiguous trend’ otherwise.

With these two statistic metrics, pathload measure the relationships between transmission rate R and available bandwidth A. Then it adjust transmission rate for different streams and use an iterative algorithm to find the available bandwidth.

1.2 Considerations about Borrowing Ideas from PathloadSince in our 2-stream problem, we always send audio packets in the fix interval, it seems we can adjust Pathload algorithm to our problem. But we must pay attention to several issues.

1.2.1 Initial value of Rmax

The natural thinking of adjust Pathload to 2-stream problem is use the iterative algorithm directly, the RCV calculate SPCT and SPDT periodically, determine where R(n)>A or not, and sends the control information back to the SND. Then SND adjust sending rate according to the iterative algorithm.

But the problem is how to set initial value of Rmax. According to [2], Pathload determine initial Rmax according to the following formula:

R=L/T.They know the R first and set T by experience value, then determine the size L. But in our case, T is fixed and we know nothing about R at the beginning of the transformation! So we cannot do the same thing here.

1.2.2 How to adjust R(n) after Rmax and Rmin fall in the resolution?If we use the iterative algorithm to calculate the next sending rate R(n+1), then comes another problem. Pathload will terminates after Rmax-Rmin , but in our case we still need to go after that! So we must figure out some way to adjust R(n) after Rmax and Rmin converges.

Suppose when Rmax and Rmin converges, the sending rate is R(n). In the next video transformation interval, we have 3 situations:1) R(n) A, this the best one, we just keep the sending rate.2) R(n) > A, we need to lower the sending rate. One solution is keep Rmax, set Rmin=0,

then R(n+1) = Rmax/2, continue with the iterative algorithm.3) R(n) < A, in this case, we need to increase the sending rate. If we want to continue

with the iterative algorithm, we need to set Rmax to the higher value. Again, this is the same problem with 2.1, we need a way to estimate the max available bandwidth!!!

1.3 ModelBase on the analysis in Section 2, I come out 2 models of 2-stream problem.

1.3.1 Use the iterative algorithm to adjust sending rate of videoWe already know that the key of using iterative algorithm in our problem is to find a way to estimate maximum available bandwidth. According to [3], we can use packet dispersion technique to calculate the Rmax, sending packet pair or packet train from SND to RCV, but seems to me this technique often lower estimate the available bandwidth, which is not suitable for your purpose.Anyway, if we can find a way to estimate maximum available bandwidth, the algorithm will look like following.

Sender:

Rmin=0; Rmax=findMaxA();WHILE (Connected) {

Receive control information from RCV;IF Rmax-Rmin> // Not converge yet.IF R(n)>A

Rmax=R(n);ELSE IF R(n)<A

Rmin=R(n);ELSE

Do nothing;ENDIFR(n+1) = (Rmax+Rmin)/2;

ELSE // Rmax and Rmin have convergedIF R(n)>A

Rmin=0;R(n+1) = (Rmax+Rmin)/2;

ELSE IF R(n)<AAmax=findMaxA();IF Amax-Rmax<d// d is a parameter, here we consider Rmax Amax.

R(n+1)=R(n);ELSE

Rmax=Amax;R(n+1) = (Rmax+Rmin)/2;

ENDIFELSE

Do nothing;ENDIF

ENDIF}

Receiver:I = 0; // A flag indicate increasing trend of the stream, if R(n)>A, I=1, otherwise I=0WHILE (Connected) {

Receive audio packets from SND;Calculate SPCT and SPDT;IF SPCT>0.66 or SPDT>0.55

I = 1; // increasing trend, R(n)>AELSE IF SPCT<0.54 or SPDT>0.45

I = -1; // no-increasing trend, R(n)<AELSE

I = 0; // ambiguousENDIFSend I to SND;

}

1.3.2 Use the congestion control algorithm to adjust sending rate of video

In this model, the receiver runs the same algorithm as in the previous one, but the sender, according to the control info received from receiver, will use some congestion control algorithm, like TCP protocol.

2 Experiment and Results of 2Stream Problem

2.1 ObjectiveOur goal is to study the behavior of audio or video stream’s one way delay (OWD), PCT and PDT values. See whether these statistics information can provide us a method to measure the network congestion, so that we can come out a way to optimization the transmission of 2 stream problem.

2.2 Experiment DesignWe build our experiments on 2 extreme network conditions. One is that the video sending rate is much larger than the available bandwidth, while the other is that video sending rate is much smaller than the available bandwidth. We define 2 network conditions as the following graph.

By calculation and experiment results we know that if the video is transferred over UDP, the sending rate is approximately 1.6Mb/s (40frams/s for the test video file), so the above 2 network conditions should meet our desire.

In each experiment, video are sent in 40frames/s. Audio packets are sent every 25 millisecond. PCD and PDT data are computed every second. In the first 60 seconds we send audio packets only, then add video packets in the next 60 seconds, after that we send audio packets along for another 60 seconds. The sending time controlling mechanism is not well implemented, so the sending interval is calculated approximately.

For each condition we send video stream over TCP and UDP, then collect OWD, PCT and PDT of audio and video stream respectively. We also calculate the video sending rate and video receiving rate on the sender and receiver side based on the packet size went through the interface send(), sendto(), recv() and recvfrom().

Link 31Mb/s

Link 20.1Mb/s

Link 110Mb/s

Server(SND)

MachineI

Server(SND)

MachineII

Condition 1: Available Bandwidth 0.1Mb/s

Link 3100Mb/s

Link 2100Mb/s

Link 1100Mb/s

Server(SND)

MachineI

Server(SND)

MachineII

Condition 2: Available Bandwidth 100Mb/s

We collect the experiment data and plot them with Matlab programs. The results are given by the following graphs. OWD is given on micro second (10-6s).

2.3 ResultsThe results are attached at the end of this document. The plots for OWD, PCT and PDT are listed in four pages.

2.4 Analysis and DiscussOur most concern is to find out a suitable metric to measure the relationship between transmission rate and available bandwidth. Since we didn’t change video transmission rate in all the experiments, so the data (OWD, PCT and PDT) collected based on video packets are not so meaningful to us. We may find some transmission patterns or verify some stuff like TCP congestion control, but we cannot figure out how the statistics data will changed based on different network condition, because we have nothing to compare with if we just send video packets in a fixed rate. So one suggestion is to do some experiments in which we send video streams in different transmission rate, so we can see how the statistics data will change along vary of network congestion.

So we will focus on the analysis of audio packets. The following observations deserve our attention.

1) When we start sending video on the link with Available Bandwidth (AB) = 0.1mb/s, the average OWD of audio packets goes up on both transmission protocols, but the increasing trend is not so stable in TCP condition. The reason may be TCP congestion control take effects.

2) According to the theory behind pathload, the OWD of audio packets should keep increasing if we keep transmission rate larger than the available bandwidth. But in the experiments on AB=0.1mb/s, protocol=UDP, audio stream, we can see the OWD of audio packets increase then decrease periodically, it doesn’t show an fixed increasing trend. An explanation need here.

3) In the experiments on link 0.1mb/s, when we start transfer video at a transmission rate larger than AB, PCT and PDT didn’t measure this quite well. Take a look at the four plot of PCT and PDT for audio stream (protocol=TCP/UDP), only PDT for video sent over TCP (PDT on protocol=TCP) shows an increasing trend at the beginning of video transmission, the other 3 plot (PCT on protocol=TCP, PCT on protocol=UDP, PDT on protocol=UDP) decrease at the beginning of video transmission.

4) We provide subplots for the OWD of audio stream on link with AB=100mb/s. From the subplot we can see they show periodically peaks. The reason I guess is that there might be somewhere buffering in the transmission.

Available Bandwidth = 0.1Mb/sProtocol = TCP, Audio StreamVideo Sending Rate: 88745.802388b/sVideo Receiving Rate: 79551.279612b/s

Available Bandwidth = 100Mb/sProtocol = TCP, Audio StreamVideo Sending Rate: 1665455.475685b/sVideo Receiving Rate: 1662056.290140b/s

Available Bandwidth = 0.1Mb/sProtocol = TCP, Video StreamVideo Sending Rate: 85635.154002b/sVideo Receiving Rate: 77086.911154b/s

Available Bandwidth = 100Mb/sProtocol = TCP, Video StreamVideo Sending Rate: 1664153.610806b/sVideo Receiving Rate: 1660757.856125b/s

Available Bandwidth = 0.1Mb/sProtocol = UDP, Audio StreamVideo Sending Rate: 1664114.699721b/sVideo Receiving Rate: 82840.582939b/s

Available Bandwidth = 100Mb/sProtocol = UDP, Audio StreamVideo Sending Rate: 1664143.622185b/sVideo Receiving Rate: 1665237.745048b/s

Available Bandwidth = 0.1Mb/sProtocol = UDP, Video StreamVideo Sending Rate: 1664121.553659b/sVideo Receiving Rate: 83073.772160b/s

Available Bandwidth = 100Mb/sProtocol = UDP, Video StreamVideo Sending Rate: 1664136.922501b/sVideo Receiving Rate: 12497446.000000b/s

Available Bandwidth = 100Mb/sProtocol = TCP, Audio StreamVideo Sending Rate: 1665455.475685b/sVideo Receiving Rate: 1662056.290140b/s

Subplot1: Packets 0 - 300

Subplot2: Packets 1100 - 1300 Subplot3: Packets 2300 - 2500

Subplot1: Packets 0 - 300

Subplot2: Packets 1100 - 1300 Subplot3: Packets 1400 - 1600

Subplot4: Packets 2300 - 2500

Available Bandwidth = 100Mb/sProtocol = UDP, Audio StreamVideo Sending Rate: 1664143.622185b/sVideo Receiving Rate: 1665237.745048b/s