WFQ fragmentation issue

Unanswered Question
Apr 1st, 2009

In WFQ implementation of CISCO routers it is said that WFQ is (as in most cases) bit-wise.

Assuming that there are 3 traffic flows: voice packets (small packets around 90 bytes/packet), video packets (larger packets around 1400 bytes/packet) and FTP packets (around 1300 bytes/packet) with corresponding weights of 60, 40 and 1, how packets are delivered to the output queue for the transmission?

That is if the operation of WFQ is a bit-wise, does WFQ algorithm actually fragments the packets for transmission according to provided bandwidth (weight = flow bandwidth) and taking into account round robin fashion?

For example, in case of small voice packets, is it the case that if the weight is 60 (lets assume the corresponding bandwidth of 1000 bytes per voice flow for the output queue) then the 12th voice packet (11*90=990 bytes) will be fragmented into 10 (990+10=1000 bytes) and 80 bytes fragments and in the NEXT cycle (round robin fashion) 80 bytes of the LAST fragmented packet from the PREVIOUS cycle will be delivered first to the output queue for the transmission? Same question applies to all other flows (e.g. video and FTP).

It is a bit vaguely for me, since another term used for WFQ (for example in Parekh&Gallager paper on WFQ) is a PGPS (packet by packet transmission scheme)

meaning that WFQ treats the packets as a single entities.

If this applies to WFQ implementation on cisco routers, then my question is how it actually sets the packet length and what happens if the packet is bigger then the allocated weight as maybe in case of video packets(bandwidth)?

Thank you very much in advance!


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)


This Discussion