2

I have a Cisco 3845 running IOS 15.3(3)XB12 which is accepting synchronous MLPPP calls from ISDN lines via a PRI. I want to reduce the size of the output queue on the router's PPP interfaces, but the command I am using to try to do that does not appear to be having any effect.

When the router is forwarding data to a client at the full line rate, packets going across the link experience a lot (multiple seconds) of latency. The cause of this appears to be that the router has a default output queue size of 40 packets on the Virtual-Access interfaces which get created for each MLPPP session. I want to attempt to reduce this latency by reducing the number of packets the router will queue to send to each client.

The Virtual-Access interfaces are cloned from the Dialer interface associated with the D channel of my PRI, so I added the following commands to my Dialer interface: 

 hold-queue 5 in
 hold-queue 5 out

(Note that the "hold-queue 5 in" is just there for comparison; I don't actually need to alter the size of the input queue.)

After making these changes and starting a new client dial-in session, it appears that the input queue size change took effect but the output queue size change did not: 

#show int virtual-access 3
Virtual-Access3 is up, line protocol is up
  Hardware is Virtual Access interface
  MTU 1500 bytes, BW 128 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 21/255, rxload 5/255
  Encapsulation PPP, LCP Open, multilink Open
  Open: IPCP
  MLP Bundle vaccess, cloned from Dialer10
  Vaccess status 0x44, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:00:00, output never, output hang never
  Last clearing of "show interface" counters 00:48:39
  Input queue: 0/5/0/0 (size/max/drops/flushes); Total output drops: 3
  Queueing strategy: fifo
  Output queue: 35/40 (size/max)
  5 minute input rate 3000 bits/sec, 7 packets/sec
  5 minute output rate 124000 bits/sec, 10 packets/sec

Starting a download on the connected client then pinging across the link results in 3+ seconds of latency, which is about what you would expect from a 40-packet output queue on the router interface (40 packets in the queue * 1500 bytes per packet * 8 bits per byte / 128000 bits per second = 3.75 seconds max queue time).

For reference, here are the complete configurations of the Dialer and D-channel interfaces: 

interface Dialer10
 ip unnumbered Loopback3
 encapsulation ppp
 no ip route-cache cef
 dialer in-band
 dialer idle-timeout 0
 dialer-group 5
 peer default ip address pool isdn
 no cdp enable
 hold-queue 5 in
 hold-queue 5 out

interface Serial3/0:23
 no ip address
 encapsulation ppp
 no ip route-cache cef
 dialer rotary-group 10
 dialer-group 5
 autodetect encapsulation ppp v120
 isdn switch-type primary-ni
 isdn incoming-voice modem
 ppp authentication chap
 ppp multilink
 no cdp enable

Does anyone have any idea why this change seems to be taking effect for the interface input queue but not the output queue, or what the correct way is to alter the output queue size?

Note 1: This question is different than the one here, which this was marked as a duplicate of. That question is about trying to get a router to generate ICMP Source Quench messages, which I am not trying to do. The document linked to as an answer to that question discusses how to adjust a router's strategy for allocating shared buffer resources between busy interfaces, which is also not what I am trying to do. I am trying to reduce the output queue length of a single interface.

Note 2: Through further experimentation, I have found that my

hold-queue 5 out

directive on the Dialer actually does take effect, just not on the first time a given cloned Virtual-access interface comes up. Once a Virtual-access interface has come up, then been torn down due to a hangup, it will come up with an output queue size of 5 on all subsequent connections. If anyone knows why this is or what to do about it, I would still be very interested to know.

Otherwise, I will pursue one of the suggested alternate approaches (QoS queue-limits and/or RED).

Juffo-Wup
  • 181
  • 1
  • 8
  • "_I want to attempt to reduce this latency by reducing the number of packets the router will queue to send to each client._" That will not lower the latency, and could, in fact, increase the latency because packets unable to be queued will be dropped. It's not that the router queues things until the queue is full, then sends. A packet arriving at an empty queue will be sent immediately. Packets are queued when too many packets arrive to be sent immediately, and while a packet is being sent, other packets arriving will be kept in the queue. You may have a problem where the queue is too small. – Ron Maupin Mar 12 '19 at 20:32
  • @RonMaupin Right; I'm considering the case where a packet arrives at the interface when its queue is almost full. If the packet is 40th in line in the queue (assuming the queue mostly contains 1500 byte packets), it will have to wait in the queue for 3,750 ms while the packets ahead of it in line are sent. I would prefer to limit the queue to a smaller size so that packets arriving when more than, say, 5 or 10 packets are already in the queue are dropped. TCP should back off (as it does now when the queue gets full), and packets that do make it into the queue will not have to wait as long. – Juffo-Wup Mar 12 '19 at 20:57
  • Keep in mind that this is a much slower interface than most that people work with these days. I don't know what a good output queue length is, but I do suspect that it is less than 40 (which represents 3,750 ms of queueing at line rate). – Juffo-Wup Mar 12 '19 at 20:57
  • Then what you want is QoS, and you should enable RED. The TCP timeout is going to take the more time, regardless, because TCP has no way to know if the queue dropped it, or if the ACK was never received, for whatever reason. TCP will also adjust to slow times. I think the way you want to go about this is misguided. You may end up suffering from TCP global synchronization in any scenario, which is why you want RED. – Ron Maupin Mar 12 '19 at 21:08
  • Having done some reading, it does sound like RED would do what I want. It still seems to me that reducing the output queue size would also do what I want, but I am making some simplifying assumptions about the traffic that will be going over these links. I think that both methods would work for the traffic I expect, but RED would be more generally applicable. I will keep looking at it and, if I ever do figure out how to adjust the queue size, maybe I will do a side by side comparison with a couple traffic mixes and compare the results. – Juffo-Wup Mar 12 '19 at 22:58
  • 3
    By using QoS, you can determine the queue size, and you can use RED on the various queues you create. – Ron Maupin Mar 12 '19 at 23:14
  • 1
    There is a two-part answer to [this question](https://networkengineering.stackexchange.com/q/42660/8499) that explains QoS, and there are a lot of other answers here, including some I answered. You can get a good idea about using it. – Ron Maupin Mar 12 '19 at 23:16
  • There is actually an answer (mine) to that question that explains how to use QoS to adjust the queue size. – Ron Maupin Mar 13 '19 at 23:40
  • @RonMaupin Curiously, creating a policy-map specifying a queue-limit and attempting to apply it to the Dialer interface causes it to instead be applied to the PRI D-channel interface Serial3/0:23. This does have the desired effect on incoming non-multilink PPP calls, but it causes incoming multilink PPP calls to fail entirely for reasons I am yet to understand. These comments have a fairly strict character limit, so perhaps this calls for a separate question if I can't figure it out myself. – Juffo-Wup Mar 17 '19 at 18:18

0 Answers0