From: Peter Shipley <shipley@tfs.COM>
Date: Thu, 12 Aug 93 14:58:13 PDT
To: smb@research.att.com
Subject: Re: Secure voice software issues
In-Reply-To: <9308122055.AA27140@toad.com>
Message-ID: <9308122154.AA18473@edev0.tfs.com.TFS>
MIME-Version: 1.0
Content-Type: text/plain


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