Re: Secure voice software issues

> do not use error correction or compression.  (they will slow you down)

huh?!?  my file transfer times would *double* if i turned off v.42bis
(modem compression).  *that* would slow me down.  and you can't run
v.42bis without running the error handling protocol (v.42), for obvious
reasons.  what's more, v.42 gives an immediate 20% (or so) increase in
throughput, by eliminating start and stop bits.

arguably, i could (and should) be running compression in my slip or ppp
driver, but certainly it is false to say that v.42bis and v.42 slow me
down -- the opposite is true.

> and tcp does it's own error correction.  as for 160ms round trip times
> that is acceptable for slip.

i don't much care about round-trip times, as i use my slip line principally
for afs, which runs as a data stream.  round-trip delays are amortized over
file transfers.

phil karn's points about modem buffering interfering with type-of-service
queueing are the strongest condemnations of modern modems, in my view.
i wish someone would build a modem that recognized ip packet framing.

	peter

>> do not use error correction or compression.  (they will slow you down)

>huh?!?  my file transfer times would *double* if i turned off v.42bis
>(modem compression).  *that* would slow me down.  and you can't run
>v.42bis without running the error handling protocol (v.42), for obvious
>reasons.  what's more, v.42 gives an immediate 20% (or so) increase in
>throughput, by eliminating start and stop bits.

I think there's a confusion here between the conflicting goals of low
delay and high throughput. Depending on which is more important to
your application, V.42bis will either "slow you down" or "speed you
up". Unfortunately, most modems don't give the user any way to say
whether delay or throughput is more important to you at the moment;
the modems themselves try to infer this automatically from the data
streams you send them. And they bias the decision in favor of greater
throughput. This is right for most computer applications, but not so
for real time voice.

Phil

> phil karn's points about modem buffering interfering with type-of-service
> queueing are the strongest condemnations of modern modems, in my view.
> i wish someone would build a modem that recognized ip packet framing.

This is why you'd really want to run your modems synchronously.  You'd
just send HDLC frames that encapsulated IP packets (fragmentation may
be required).  This is how most IP routers work over serial links.

>This is why you'd really want to run your modems synchronously.  You'd
>just send HDLC frames that encapsulated IP packets (fragmentation may
>be required).  This is how most IP routers work over serial links.

Indeed. And because LAPM uses HDLC framing over the modem, you could
be completely compatible with a regular (asynch DTE interface) V.42bis
modem on the other end of the call. But by implementing V.42bis
yourself, you would have complete control over when frames get sent,
and how large they are.

Phil