Re: Secure voice software issues

I see 160ms round trip times on my SLIP link from home to work, and I
	 can't account for all of this time by just adding up transmission
	 times and store-and-forward delays for the data rates and packet sizes
	 I'm using. And I don't think it can be explained by the trellis
	 decoding in V.32 bis, as that should account for only a few bits of
	 delay.

	 I've since heard of very similar figures for other modems, so It's not
	 just my modem. I'm beginning to suspect the V.42bis packetizing
	 algorithms. Although they're not described in the spec, I suspect that
	 real V.42bis implementations use timers to determine when to send the
	 the currently queued data as a frame. Or maybe there's a Nagle-like
	 algorithm like the one in TCP: immediately send the first byte of data
	 on an idle link, but keep additional traffic pending until the first
	 byte is acknowledged in order to aggregate stream traffic into larger
	 frames.

	 This is all speculation so far, but it does explain the long RTTs I
	 see with packet traffic even though raw character-at-a-time traffic
	 seems to be fast.  Stream traffic would see the worst delays of all,
	 which is ordinarily okay for a file transfer, but death to a real time
	 stream like voice. That's why we may be forced to turn off V.42
	 entirely and speak synchronously to the modem.

	 Time to haul out a protocol analyzer and do some timing measurements.

Real timing measurements would help, but it's not just the V.42bis
algorithms.  A year or two ago, I did some measurements on a number
of different modems.  I saw large -- and sometimes unacceptable -- delays
even without V.42 or MNP in use.  My methodology was to enable loopback
at various points -- hardware loopback plugs, local loopback on my
modem, remote loopback or a plug at the far end, etc.  I sent single
characters, and timed how long they took to show up.  The modems
seem to either buffer up several characters, or have to wait a while
before sending the first one, but the delays appeared to be for the
first character in a ``bunch'' (``packet'' is too strong a word).

>	 I see 160ms round trip times on my SLIP link from home to work, and I
>	 can't account for all of this time by just adding up transmission
>	 times and store-and-forward delays for the data rates and packet sizes
>	 I'm using. And I don't think it can be explained by the trellis
>	 decoding in V.32 bis, as that should account for only a few bits of
>	 delay.
>
>	 I've since heard of very similar figures for other modems, so It's not
>	 just my modem. I'm beginning to suspect the V.42bis packetizing
>	 algorithms. Although they're not described in the spec, I suspect that
>	 real V.42bis implementations use timers to determine when to send the
>	 the currently queued data as a frame. Or maybe there's a Nagle-like
>	 algorithm like the one in TCP: immediately send the first byte of data
>	 on an idle link, but keep additional traffic pending until the first
>	 byte is acknowledged in order to aggregate stream traffic into larger

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.

>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.

Well, in theory turning off V.42bis entirely should get rid of these
delays, but in my exerience with Motorola Codex 3260 modems, it doesn't.
Don't know why.

Also, if you turn off LAPM you are back to sending start/stop bits again.

Phil

>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