Re: Secure voice software issues

Phil Karn <karn@qualcomm.com> wrote:

[Re: squeezing 13.3 kbps data w/o start&stop bits over modem] 

> Whenever V.42 error correction (LAPM) is enabled,
> synchronous HDLC frames are what actually pass over the
> link. So the start/stop bits are already removed. 

> Unfortunately, the packetizing done by LAPM adds delay
> we don't want for a real time voice application. And if you
> turn off LAPM, you return to sending the start/stop bits
> over the wire.

Well...  How much latency does LAPM really add?  Little enough that  
full duplex keystrokes echo back nearly instantly on my connections.   
People talk over satellite links with more delay than that all the  
time.  Since we're not going to get toll quality voice out of the  
vocoders anyway, and the error correcting stuff is especially useful  
for encrypted data streams...  I think V.42 is probably a good idea  
for a cryptophone project. 


> Most V.32 and V.32bis modems provide for direct
> synchronous operation, which would let us have our cake
> and eat it too, except that few PCs can speak
> synchronously to a modem. This may require some extra
> hardware (sigh).

I'm in favor of getting a minimal version that will run on the lowest  
common denominator hardware first.   (Might have something to do with  
the fact that I just spent a couple hundred dollars on an internal  
V.32bis modem that doesn't do synchronous :^)

Joe

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.

Phil