Weighted Fair-Queuing

Discussion in 'Cisco' started by Martin Bilgrav, Oct 30, 2003.

  1. Hiya,

    I was just reading a book about WAN etc, and I am started to wonder how WFQ
    must be configured.

    ex:
    Clients----router1---[45 mbit WAN]----router2-----servers
    flow direction --->

    With the above schema, which interfaces must I place the "Fair queuing"
    Statment, for standard Flowbased WFQ ?

    Is it on clients side interface on router1 or ?
    Do I have to (or is it smart) to place it on both ends ?
    Or is it just to put it on the WAN interfaces ?

    Or how ?

    Kind regards
    Martin Bilgrav
    Martin Bilgrav, Oct 30, 2003
    #1
    1. Advertising

  2. You cannot use weighted fair queuing on high bandwidth links like yours.
    You must use some other type of queuing since WFQ does not scale above
    2Mbits/sec links.
    BSOF


    "Martin Bilgrav" <> wrote in message
    news:Sjdob.15917$...
    > Hiya,
    >
    > I was just reading a book about WAN etc, and I am started to wonder how

    WFQ
    > must be configured.
    >
    > ex:
    > Clients----router1---[45 mbit WAN]----router2-----servers
    > flow direction --->
    >
    > With the above schema, which interfaces must I place the "Fair queuing"
    > Statment, for standard Flowbased WFQ ?
    >
    > Is it on clients side interface on router1 or ?
    > Do I have to (or is it smart) to place it on both ends ?
    > Or is it just to put it on the WAN interfaces ?
    >
    > Or how ?
    >
    > Kind regards
    > Martin Bilgrav
    >
    >
    Balin, Son of Fundi, Oct 30, 2003
    #2
    1. Advertising

  3. "Balin, Son of Fundi" <> wrote in message
    news:bnrnvi$14hve8$-berlin.de...
    > You cannot use weighted fair queuing on high bandwidth links like yours.
    > You must use some other type of queuing since WFQ does not scale above
    > 2Mbits/sec links.
    > BSOF
    >



    okay, let's say its a 1 mbit link then 8)



    >
    > "Martin Bilgrav" <> wrote in message
    > news:Sjdob.15917$...
    > > Hiya,
    > >
    > > I was just reading a book about WAN etc, and I am started to wonder how

    > WFQ
    > > must be configured.
    > >
    > > ex:
    > > Clients----router1---[45 mbit WAN]----router2-----servers
    > > flow direction --->
    > >
    > > With the above schema, which interfaces must I place the "Fair queuing"
    > > Statment, for standard Flowbased WFQ ?
    > >
    > > Is it on clients side interface on router1 or ?
    > > Do I have to (or is it smart) to place it on both ends ?
    > > Or is it just to put it on the WAN interfaces ?
    > >
    > > Or how ?
    > >
    > > Kind regards
    > > Martin Bilgrav
    > >
    > >

    >
    >
    Martin Bilgrav, Oct 30, 2003
    #3
  4. "Balin, Son of Fundi" <> wrote in message
    news:bnrnvi$14hve8$-berlin.de...
    > You cannot use weighted fair queuing on high bandwidth links like yours.
    > You must use some other type of queuing since WFQ does not scale above
    > 2Mbits/sec links.


    Actually there is no speed limit.

    However, as a general rule it is not a good choice for links over 2Mb
    because
    of the high cpu-power needed for high speed links. That's why FWQ is on by
    default for links below 2Mbit while FIFO is the default for links 2Mbit and
    above.

    There are other matters like packet size which affect this. 1,5Mbit of
    64-byte
    packets loads the cpu much more than 4 Mbit of 1500-byte packets. Using
    wfq for that 4 Mbit link is very realistic in many cases whereas it is quite
    a heavy
    task for the 1,5Mbit link pushing lots of tiny packets.

    Queueing is a job requiring per-packet choises. For every packet you make a
    selection about which one to send and for every inbound packet you have to
    put it into some queue or drop it. Therefore the caused cpu load is related
    with
    packets per second, not the actual data streem bits/sec. (On some platforms
    packet size does couse loading too but for some other reasons related more
    to the memory management of the device).

    Configuration is simple. Queueing is used when the interface hardware
    outbound
    queue is full. It is used on the outbound interface only. Software queueing
    is never
    used for inbound packets.

    Inbound packets are always processed sequentally or dropped.

    Notice that queueing is done for every PHYSICAL interface only. It is not
    done for subinterfaces. So, for example many dot1q vlans on same interface
    must use the common queue used for the single physical interface.
    --
    Harri
    Harri Suomalainen, Oct 31, 2003
    #4
  5. "Harri Suomalainen" <> wrote in message
    news:_Uoob.77$...
    >
    > Configuration is simple. Queueing is used when the interface hardware
    > outbound
    > queue is full. It is used on the outbound interface only. Software

    queueing
    > is never
    > used for inbound packets.
    >
    > Inbound packets are always processed sequentally or dropped.
    >
    > Notice that queueing is done for every PHYSICAL interface only. It is not
    > done for subinterfaces. So, for example many dot1q vlans on same interface
    > must use the common queue used for the single physical interface.


    Hi,
    Thz for the inligthning answer.
    Tell me more on the config part:
    Do you config FWQ on both end routers WAN INterfaces, or just one ?
    I mean if your router1 trottles down the flow, then you properbly never will
    se higher flow on router2, hence the queuing will never engage ?

    Or am I misinterpriating this.

    regards
    Martin
    Martin Bilgrav, Oct 31, 2003
    #5
  6. Martin Bilgrav

    CCIE8122 Guest

    >>Configuration is simple. Queueing is used when the interface hardware
    >>outbound queue is full. It is used on the outbound interface only. Software queueing
    >>is never used for inbound packets.
    >>
    >>Inbound packets are always processed sequentally or dropped.
    >>
    >>Notice that queueing is done for every PHYSICAL interface only. It is not
    >>done for subinterfaces. So, for example many dot1q vlans on same interface
    >>must use the common queue used for the single physical interface.

    >
    > Hi,
    > Thz for the inligthning answer.
    > Tell me more on the config part:
    > Do you config FWQ on both end routers WAN INterfaces, or just one ?
    > I mean if your router1 trottles down the flow, then you properbly never will
    > se higher flow on router2, hence the queuing will never engage ?
    >
    > Or am I misinterpriating this.
    >
    > regards
    > Martin


    No. You are misunderstanding.

    For purposes of this discussion, queuing is is only performed on
    outbound traffic flows.

    So across a WAN (say between Rtr1 and Rtr2), with few exceptions, any
    given communication session will consist of two unidirectional traffic
    flows (each in the opposite direction). For example, if you are FTPing
    a file from Host1 (behind R1) to Host2 (behind R2), there will be a
    large data stream flowing from R1 to R2 consisting of actual chunks of
    the file. In the other direction (from R2 to R1), you will have little
    tiny TCP ACKs every once in a relative blue moon. As you can see, in
    this communication, lots of traffic is flowing one way, almost none is
    flowing the other.

    By itself, this is not an issue at all. But when you put other traffic
    on that WAN link, the more interactive stuff has a tendency to get
    crowded out by the file I/O blasts such as FTP, SMTP, NetBT, etc. So .
    .. . queuing.

    In order to address this problem, you only need traffic queued in an
    intelligent way on R1. The reason is that R2 will never queue a packet
    because it is only sending ACKs every once in a while -- not nearly
    enough to saturate the link.

    In simplistic terms, the queuing algorithm on R1 will play traffic cop
    and start queuing FTP packets behind the packets of other flows (or
    rather, at least more fairly). Thus every flow gets an equal share of
    the bandwidth (FQ is only WFQ if you have traffic of differing ToS).

    Now, this does not mean that you dont need to configure queuing on R2,
    because a different file I/O session might begin from behind R2 destined
    for a host behind R1. And you dont want your ACKs from the H1-H2 FTP
    session to be lost, otherwise you get data retransmits--which is about
    the worst thing for a congested link.

    So you implement queuing on R2 to handle totally different traffic
    flows. There is nothing that says you have to configure QoS on both
    sides the same--it really depends on what kind of traffic you have going
    which way. If they are substantially the same, then so will be your
    queuing strategy.

    As far as configuration, that is the easy part. Do nothing. On T1/E1
    and below, WFQ is on by default. If it has been disabled, just type
    "default fair-queue" on the interface. The way to tell if WFQ is on,
    just look at the config-- if you see "no fair-queue" on the int, then
    you are doing FIFO queueing; or if you see "priority-list x" or
    "queue-list x" or other similar line on the int, then you are doing more
    fancy type of queueing.

    (You can also do a "show int" and look for "queuing strategy" about
    half-way down).

    HTH

    kr
    CCIE8122, Nov 1, 2003
    #6
  7. "CCIE8122" <> wrote in message
    news:bo19g8$fk3$...

    > No. You are misunderstanding.
    >

    Thanks for clarifying this.

    > For purposes of this discussion, queuing is is only performed on
    > outbound traffic flows.
    >


    >
    > But when you put other traffic
    > on that WAN link, the more interactive stuff has a tendency to get
    > crowded out by the file I/O blasts such as FTP, SMTP, NetBT, etc. So .
    > . . queuing.
    >

    yes, I was thinking windows client-server environments.
    So queuing will be a great idea in such, right ?

    > In order to address this problem, you only need traffic queued in an
    > intelligent way on R1. The reason is that R2 will never queue a packet
    > because it is only sending ACKs every once in a while -- not nearly
    > enough to saturate the link.
    >

    But in windows client-server senarios, you will see users put files, but
    also you will see them get files, so the pattern is almost same in both
    directions.
    Also you have the windows generated traffic, such as NBT, NS etc, and all
    RPC stuff, and shares, printers etc.
    Print job tend to get higher filesize after spooling.

    >
    > Now, this does not mean that you dont need to configure queuing on R2,
    > because a different file I/O session might begin from behind R2 destined
    > for a host behind R1. And you dont want your ACKs from the H1-H2 FTP
    > session to be lost, otherwise you get data retransmits--which is about
    > the worst thing for a congested link.
    >
    > So you implement queuing on R2 to handle totally different traffic
    > flows. There is nothing that says you have to configure QoS on both
    > sides the same--it really depends on what kind of traffic you have going
    > which way. If they are substantially the same, then so will be your
    > queuing strategy.

    ok, same-same in both ends then.

    >
    > As far as configuration, that is the easy part. Do nothing. On T1/E1
    > and below, WFQ is on by default. If it has been disabled, just type
    > "default fair-queue" on the interface. The way to tell if WFQ is on,
    > just look at the config-- if you see "no fair-queue" on the int, then
    > you are doing FIFO queueing; or if you see "priority-list x" or
    > "queue-list x" or other similar line on the int, then you are doing more
    > fancy type of queueing.


    Does Cisco have any whitepapers for windows client-server over WAN ?
    like what traffic to put in what order in the priority lists ?

    >
    > (You can also do a "show int" and look for "queuing strategy" about
    > half-way down).
    >
    > HTH

    Sure did - thz

    >
    > kr
    >


    Martin
    Martin Bilgrav, Nov 2, 2003
    #7
  8. Martin Bilgrav

    CCIE8122 Guest

    >>For purposes of this discussion, queuing is is only performed on
    >>outbound traffic flows.

    >
    >>But when you put other traffic
    >>on that WAN link, the more interactive stuff has a tendency to get
    >>crowded out by the file I/O blasts such as FTP, SMTP, NetBT, etc. So .
    >>. . queuing.

    >
    > yes, I was thinking windows client-server environments.
    > So queuing will be a great idea in such, right ?


    Yes, queuing will kind of referree them.

    >>In order to address this problem, you only need traffic queued in an
    >>intelligent way on R1. The reason is that R2 will never queue a packet
    >>because it is only sending ACKs every once in a while -- not nearly
    >>enough to saturate the link.

    >
    > But in windows client-server senarios, you will see users put files, but
    > also you will see them get files, so the pattern is almost same in both
    > directions.


    Yes, but the flows are distinct.

    Even if I am putting a file and getting a file between the same two
    stations, there would actually at least be four flows--one for each
    direction for each transfer.

    > Also you have the windows generated traffic, such as NBT, NS etc, and all
    > RPC stuff, and shares, printers etc.


    Right, that makes it even more complex than just two flows per xfer.

    > Print job tend to get higher filesize after spooling.


    Uggh. Who prints over the WAN?

    :)

    >>Now, this does not mean that you dont need to configure queuing on R2,
    >>because a different file I/O session might begin from behind R2 destined
    >>for a host behind R1. And you dont want your ACKs from the H1-H2 FTP
    >>session to be lost, otherwise you get data retransmits--which is about
    >>the worst thing for a congested link.
    >>
    >>So you implement queuing on R2 to handle totally different traffic
    >>flows. There is nothing that says you have to configure QoS on both
    >>sides the same--it really depends on what kind of traffic you have going
    >>which way. If they are substantially the same, then so will be your
    >>queuing strategy.

    >
    > ok, same-same in both ends then.


    Unless you have disparate traffic patterns in opposite directions, yes
    your queuing strategy would be same on each side.

    >>As far as configuration, that is the easy part. Do nothing. On T1/E1
    >>and below, WFQ is on by default. If it has been disabled, just type
    >>"default fair-queue" on the interface. The way to tell if WFQ is on,
    >>just look at the config-- if you see "no fair-queue" on the int, then
    >>you are doing FIFO queueing; or if you see "priority-list x" or
    >>"queue-list x" or other similar line on the int, then you are doing more
    >>fancy type of queueing.

    >
    > Does Cisco have any whitepapers for windows client-server over WAN ?
    > like what traffic to put in what order in the priority lists ?


    Not that I am aware of.

    Because the majority of Windows stuff rides TCP over the WAN, there is
    usually no need to get fancy. TCP is pretty resilient to back off.

    If however you have a lot of flows, and are finding a lot of global
    synchronization (i.e., all TCP sessions back off at the same time, then
    throttle up at the same time, back and forth), you may want to configure
    random early detect. RED is congestion avoidance rather than congestion
    management -- the theory is, randomly discard a packet as stuff gets
    more congested. TCP will respond by throttling back only a bit. Since
    this is done randomly, you will not see the sync problem.

    >>(You can also do a "show int" and look for "queuing strategy" about
    >>half-way down).
    >>


    I dont remember the original post, but if FQ and RED dont fix your
    issues, then you probably want to go to CQ (PQ can lead to queue
    starvation which is a b$#!@*).

    Start out simple -- analyze your traffic if possible.

    Maybe start with ftp, smtp, etc in a low bw queue, put NetBT in a higher
    queue, and everything else in default.

    As you see stuff that is not getting serviced properly, add it to a
    higher queue.

    I would be surprised, though if FQ/RED doesnt fix your issues.

    RED is real tough to configure: "random-detect" on the egress interface
    -- thats it.


    HTH

    kr
    CCIE8122, Nov 3, 2003
    #8

  9. >
    > I dont remember the original post, but if FQ and RED dont fix your
    > issues, then you probably want to go to CQ (PQ can lead to queue
    > starvation which is a b$#!@*).
    >
    > Start out simple -- analyze your traffic if possible.
    >
    > Maybe start with ftp, smtp, etc in a low bw queue, put NetBT in a higher
    > queue, and everything else in default.
    >
    > As you see stuff that is not getting serviced properly, add it to a
    > higher queue.
    >
    > I would be surprised, though if FQ/RED doesnt fix your issues.
    >
    > RED is real tough to configure: "random-detect" on the egress interface
    > -- thats it.
    >
    >


    Excellent - Thanks a bundle, Kr.

    Cya out there ...

    > HTH
    >
    > kr
    >
    Martin Bilgrav, Nov 3, 2003
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jog Dial
    Replies:
    2
    Views:
    3,525
    Jog Dial
    Nov 17, 2004
  2. Silverstrand
    Replies:
    0
    Views:
    945
    Silverstrand
    Apr 17, 2006
  3. scott

    weighted tail drop

    scott, Feb 3, 2007, in forum: Cisco
    Replies:
    0
    Views:
    1,204
    scott
    Feb 3, 2007
  4. Michael  Osten
    Replies:
    0
    Views:
    1,754
    Michael Osten
    Feb 14, 2007
  5. Jeff Miller
    Replies:
    4
    Views:
    934
Loading...

Share This Page