From: karn@qualcomm.com (Phil Karn)
Date: Thu, 12 Aug 93 12:42:54 PDT
To: jthomas@kolanut.mitre.org
Subject: Secure voice software issues
In-Reply-To: <9308121503.AA00397@kolanut>
Message-ID: <9308121939.AA12734@servo>
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
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