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
participants (3)
-
karn＠qualcomm.com -
Peter Shipley -
smb＠research.att.com