Hi I'm trying to analyse these two throughput graphs for a dissertation. Could anyone shed some light on what this actually means. FIFO looks worse (and it should be) than CBWFQ, but what does this actually mean. I'm testing QoS schemes and this result comes from a congested 2MB serial link to see how each perform sending RTP, FTP and ICMP at the same time. https://dl.dropboxusercontent.com/u/39248217/CBWFQ%20throughput.jpg https://dl.dropboxusercontent.com/u/39248217/FIFO%20throughput.jpg Thanks Dan asked 16 Apr '13, 02:18  dscott1709 edited 16 Apr '13, 02:24 |
One Answer:
As you are talking about QoS, we need more information about the other traffic that passed your device while you measured one connection and the QoS policy for CBWFQ. Without any further information, I would interpret the two graphs as follows. CBWFQ The monitored session got a bandwidth of ~72 Kbyte/s (due to the CBWFQ configuration). The spikes are possibly due to a change in the 'line usage', meaning that there was less 'other traffic' and thus your session received more bandwidth as it got available. I'm sure you know how CBWFQ works. I'm adding a link for all other readers here ;-) FIFO As the name says, the packets are routed as they come in (First In First Out). There is a strong influence on the traffic pattern of a single session based on the rest of the traffic at that time. As we don't know that, I simply guess, that there were several other session and/or protocols passing your device during the time you capture the traffic.
With FIFO the bandwidth for a certain class of traffic is totally unpredictable, as it depends on the rest of the traffic, passing a device (which itself is unpredictable). CBWFQ is not 'better' than FIFO. It is just more predictable, as you can configure which traffic gets how much bandwidth. Regards answered 16 Apr '13, 04:08  Kurt Knochner ♦ showing 5 of 12 show 7 more comments |
Thanks Kurt
I'm passing an identical traffic mix of RTP video stream, FTP and ICMP over a 2MB clock rate serial link between two Cisco routers to compare how each QoS scheme (FIFO and CBWFQ) peforms best and what happens. I've given CBWFQ precedence levels of: RTP 7 FTP 4 ICMP 1
RTP video is bursty by nature if i'm right in saying. but the FTP seemed to transfer a a pretty constant rate. ICMP is in there just for illustration as I'm fundamentally comparing UDP and TCP protocols in QoS.
Does that help to give you more insight into why these graphs are different?
Cheers Dan
If the mentioned protocols were sent over the line "in parallel", then see my explanation above.
If you sent the protocol traffic one after the other over the line, I don't have an explanation for the graphs, as there are several things that could have caused that pattern. It could be:
For a further analysis, we would need the capture files and ideally a capture file where client and server are directly connected, without the router.
When I say 'identical' I just mean from an experimental approach that I've sent the same file across in FTP, the same scene from a movie streamed using port 8554 in RTP in VLC Player and a continuous ping. The traffic mix remains constant on every experiment and is run in parallel for 2 minutes every time give or take the odd second of human delay when I'm stopping the capture, ping, stream and file transfer. It's just for consistency and that as consistent I can get in my scenario. Remember I'm not going for an optimum QoS setup, I'm measuring relative performance of FIFO vs CBWFQ.
If I don't use the routers it kinda defeats the object of my experiments as I'm testing the 'internet' scenario (albeit a very simple version) of two different networks communicating over a dedicated link.
Just wondered why these graphs are appearing so different and most importantly what are the reasons behind it?
Cheers! :-)
O.K. this is how I understand your setup.
Test #1: You start an FTP session, a video stream and a ping command in parallel on the client, while the router runs in FIFO mode.
Test #2: You repeat test#1, while the router runs in CBWFQ mode.
If that is your setup, then please see my explanation in the answer above.
The difference is simply the order in which the packets are being 'released' (sent out) by the router.
In FIFO mode, the router just sends the packets as they come in. The order of the packets is determined by the behavior of the client (and server) software (ftp, video). So, the throughput in FIFO mode is fluctuating, as the client (and server) software does not send a equally constant stream of packets.
In CBWFQ mode the router has to fulfill a QoS policy. This is (basically) done by holding back and 'reordering' packets (of different traffic classes) before the get sent out. Thus the throughput graph looks 'smoother'. Why there are those 'spikes' in the CBWFQ graph, can only be answered by looking at the capture file. If you want an explanation for that, please upload the capture file somewhere (google docs, dropbox, cloudshark.org: BEWARE privacy issues!) and post the link here.
Exactly Kurt! Spot on!
It's the spikes that are the elements I'd like to explain tbh. I've just thought that the buffer size is 1200ms on the client VLC Player, so maybe while that is filling up there is a brief moment for other traffic to grab some bandwidth?
Try these captures
https://dl.dropboxusercontent.com/u/39248217/CBWFQ%20clock%20rate%202MB.pcap
https://dl.dropboxusercontent.com/u/39248217/FIFO%20clock%20rate%202MB.pcap
Thanks
sounds like a reasonable explanation.
If you look at the IO graph, you can see a similar pattern. The bandwidth of the UDP stream (red) drops several times (maybe due to the buffers you mentioned). Unfortunately the increase in bandwidth for the TCP session is not that obvious as in the TCP stream graph. But I still think the VLC 'buffer theory' is right.
UPDATE: IO graph starts at the same time as the TCP session (same as TCP stream graph).
Now, you see the 'spikes' at the same time as in the TCP stream graph.
Interestingly I've just had another look at what goes on around the spikes. At each spike there are duplicate ACK's sent for TCP traffic. They seem to occur around 47s, 58s and 109s which is close to the spikes?? Could it be that while other FTP packets are transmitting others have been dropped and requested for retransmission, which briefly allows other packets in the sequence more throughput. This is a heavily congested line, so maybe that makes sense? I can mention both suggestions in my report anyhow because it's still critical analysis.
That's pretty normal for a QoS solution, as the router may have to drop packets to fulfill the bandwidth policy. So a QoS device will actually do these things to fulfill the QoS policy:
All pretty normal for a QoS solution, at least as I have seen it several times.
Cheers for your input Kurt. What did you think about the jitter comparisons and the RTT on the other posts?
If you think this was the correct answer that resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.
Let's close this question and discuss that in the other question.