Secure voice software issues

[karn@qualcomm.com (Phil Karn)]

>do not use error correction or compression.  (they will slow you down)
>and tcp does it's own error correction.  as for 160ms round trip times
>that is acceptable for slip.

I don't know about you, but 160ms *is* objectionable to me when typing
on a character-at-a-time telnet connection. And several people I've
tried to introduce to demand-dialed SLIP (instead of hogging annex
ports for hours with idle dumb terminals) have also complained about
the delay.

BTW, there's another problem with V.42bis compression that I haven't
mentioned yet. When you enable compression, most modems suck in
several seconds' worth of transmit data before they drop CTS to flow
control the host (this assumes the DTE speed is considerably faster
than the line speed, as it needs to be to get the most out of the
compression).

This is no problem if you're sending a large file with, say, ZMODEM;
presumably the modem buffers up all this data so it can figure out
whether to compress it or not. But this creates nasty delay problems
for SLIP/PPP when you try to mix bulk and interactive traffic streams.
Even if your router gives interactive (e.g., Telnet) packets priority
over bulk (e.g., FTP) traffic in its own interface send queues, it
can't do anything about the data that's already gone to the modem. So
if the modem buffers up 2 seconds of FTP data, then your telnet
packets will see 2 second delays even if it they have unconditional
priority in the router over your big background FTP transfer.

Worse still, some modems seem to buffer up all this data even when
you disable V.42bis compression. Sigh.

I point this out because many people would like to multiplex secure
voice with IP data over their SLIP links. This lets you use a single
phone line for voice and data simultaneously (especially if you have a
variable rate vocoder), and it lets you use the Internet for voice.
Not only does this let you bypass the long distance network, but it
would make a pen register on your modem line almost useless. It would
just show that you frequently call a local SLIP server to which you
presumably have legitimate access. :-)

But there are some problems yet to be solved. I'm rapidly coming to
the conclusion that the only way around the SLIP/PPP modem buffer/delay
problems is to speak raw synchronous data to the modems, even to the
point of implementing V.42bis and HDLC in the host computer instead of
using the modem's implementation.

Phil