[Asterisk-Users] tcp/ip stack tweaks

[Vic Cross]

On Mon, 12 Apr 2004, Scott Laird wrote:

> I mean, even G.711 is only ~80 kbps (including overhead), so you 
> should be able to run hundreds of simultaneous conversations on 100 
> Mbps Ethernet without running out of bandwidth.

Disclaimer: I do not build networks for a living -- the following comes
from years of working near people who do, as well as a more-than-passing
interest in making networks work well.

Usually the LAN is not the problem.  Wide-area links (such as your
Internet connection) are where attention must be paid.  ~80kbps is not
much traffic, sure, but making sure that the packets that comprise that
flow are delivered in a timely manner -- and not swamped by someone
streaming video or doing a Windows Update -- is the trick.  Even a
T1/E1-sized IP link to head-office will give you grief if you're trying to
conduct low-latency traffic at the same time as the VP's assistant sends
the 50MB all-staff Xmas-Party-Invite.doc via e-mail... :)

The problem can be in buffer sizes.  One trick that router admins used to
use to keep WAN links busy and happy (particularly links with a high
round-trip-time such as satellite) was to increase the length of the
transmission queues and the transmit and receive windows -- increasing the
number of packets that get lined up for transmission, and making it more
likely that we've continued transmitting instead of waiting for
acknowledgements.  This will utterly destroy anything real-time, as any
large transfer will fill up the longer queue all at once (you'll know what
I mean if you've ever tried to use telnet or SSH over a link that's
simultaneously filled up with a big FTP or HTTP download, or the above
example e-mail).  So, the trick was to keep the queue short enough to
maintain some degree of interactiveness, yet long enough that the link is
kept active.  Nowadays, we can use QoS and priority queueing to put
interactive stuff straight to the front of the queue -- but we still have
to hope that our ISPs and carriers treat that the same as we do.

(Speaking of window sizes, I've heard that for extreme performance it is
not wise to mix TCP and UDP on the same interface because of the different
ways that windows and buffers are sized with TCP and UDP...  I don't know
enough to confirm or refute this.  I can imagine that TCP's method of
setting the window size -- blast it out until it doesn't fit any more --
might cause a problem for a UDP-based RTP stream already in-flight...  
Comments?)

Back to LANs: it is possible to see problems on very busy Ethernets.  In
unswitched networks, if utilisation is high, collisions are more likely
(we don't call it Crashernet for nothing).  This might be sufficient to
give you some loss of quality, or at least start to exercise your jitter
buffering.  In switched networks, if your backbone is being overworked you
may get packet loss etc.  Neither of these situations are directly helped
by QoS -- if your packet can't get on the wire, or gets thrown off later,
a few bits in a header won't change that much (although some routers and
switches may make traffic with identified QoS less likely to be thrown out
-- kind-of like how the Discard Eligible bit is used in Frame Relay).


Cheers,
Vic Cross