This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

FIFO vs CBWFQ throughput graph comparison

0

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's gravatar image

dscott1709
11335
accept rate: 0%

edited 16 Apr '13, 02:24


One Answer:

0

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 ;-)

http://www.youtube.com/watch?v=9oFLCrVrQLQ

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.

FIFO looks worse (and it should be) than CBWFQ, but what does this actually mean.

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
Kurt

answered 16 Apr '13, 04:08

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

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

(17 Apr '13, 03:05) dscott1709

I'm passing an identical traffic mix of RTP video stream, FTP and ICMP over a 2MB clock rate serial link

  • in parallel or one after the other?
  • If "in parallel", can you please add the graphs for the other protocols, generated from the same capture file, for the same time interval?
  • How do you generate an identical traffic mix for different protocols?

Does that help to give you more insight into why these graphs are different?

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:

  • the FIFO implementation in the Cisco router
  • client IP stack
  • server IP stack

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.

(17 Apr '13, 12:39) Kurt Knochner ♦

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! :-)

(18 Apr '13, 15:48) dscott1709

Just wondered why these graphs are appearing so different and most importantly what are the reasons behind it?

O.K. this is how I understand your setup.

client --- router --- server

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.

(18 Apr '13, 16:13) Kurt Knochner ♦

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

(18 Apr '13, 16:46) dscott1709

so maybe while that is filling up there is a brief moment for other traffic to grab some bandwidth?

sounds like a reasonable explanation.

(18 Apr '13, 17:00) Kurt Knochner ♦
1

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.

http://img7.imageshack.us/img7/5916/iograph.jpg

(18 Apr '13, 17:26) Kurt Knochner ♦
1

UPDATE: IO graph starts at the same time as the TCP session (same as TCP stream graph).

http://postimg.org/image/xc6fldusd/
https://dl.dropboxusercontent.com/u/39248217/CBWFQ%20throughput.jpg

Now, you see the 'spikes' at the same time as in the TCP stream graph.

(18 Apr '13, 17:47) Kurt Knochner ♦

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.

(19 Apr '13, 03:43) dscott1709

At each spike there are duplicate ACK's sent for TCP traffic.

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:

  • reorder packets for different traffic classes on the outgoing interface
  • holding back packets
  • dropping packets (if the buffers are full)

All pretty normal for a QoS solution, at least as I have seen it several times.

(19 Apr '13, 03:52) Kurt Knochner ♦

Cheers for your input Kurt. What did you think about the jitter comparisons and the RTT on the other posts?

(19 Apr '13, 07:13) dscott1709

Cheers for your input Kurt.

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.

What did you think about the jitter comparisons and the RTT on the other posts?

Let's close this question and discuss that in the other question.

(20 Apr '13, 05:48) Kurt Knochner ♦
showing 5 of 12 show 7 more comments