| |
PA2AGA > TCPDIG 07.09.96 06:00l 203 Lines 8093 Bytes #-10894 (0) @ EU
BID : TCP_96_182
Read: DG7DAH GUEST
Subj: TCP-Group Digest 96/182
Path: DB0AAB<DB0KCP<DB0ZKA<DB0LX<DB0RBS<DB0SEL<DB0ZDF<DB0AIS<DB0NDK<DB0ACH<
DB0ACC<PI8DRS<PI8DAZ<PI8GCB<PI8MBQ<PI8VNW
Sent: 960907/0042Z @:PI8VNW.#ZH2.NLD.EU #:62847 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA17151 ; Sat, 07 Sep 96 00:04:54 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.61/7.1) with SMTP
id AA00004253 ; Sat, 07 Sep 96 01:15:05 MET
Received: from pa2aga-10 by pa2aga with SMTP
id AA00004225 ; Sat, 07 Sep 96 01:08:31 MET
Received: from pa2aga-10 by pa2aga-10 (NET/Mac 2.3.61/7.1) with SMTP
id AA00005441 ; Sat, 07 Sep 96 01:08:25 MET
Date: Thu, 05 Sep 96 16:34:23 MET
Message-Id: <tcp_96_182>
From: pa2aga
To: tcp_broadcast@pa2aga-10
Subject: TCP-Group Digest 96/182
X-BBS-Msg-Type: B
TCP-Group Digest Thu, 5 Sep 96 Volume 96 : Issue 182
Today's Topics:
200 kbps
PPP/SLIP in connected AX25? (3 msgs)
Radio Links and AX.25 backoff
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Wed, 4 Sep 1996 17:30:39 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Subject: 200 kbps
>Speaking of speed. Here's an interesting web page:
>http://www.wcrb.com/FMDigital/NAB96.html
>It concerns the use of direct digital in commercial FM.
Interesting. The very high bits/sec/Hz figures cited (5-6 bps/Hz),
plus the fact that the data stream is overlaid on a normal FM stereo
signal using a subcarrier, tells me this scheme can work only because
FM broadcast stations already run such large amounts of power. It
seems much less interesting for amateur applications.
Phil
------------------------------
Date: Wed, 4 Sep 1996 14:39:18 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Subject: PPP/SLIP in connected AX25?
>Also the X.25 related rfc1598 tells that FULL duplex operations are a
>MUST ! Maybe I'm wrong, but for me FULL duplex means RX+TX at the same
>time ! Is this FULL duplex operation really a must or is it possible to
>work with the "normal" equipment which is out there ?? For the user
>group we have in mind it has to work with what is there.
The full duplex "requirement" simply means that if the physical medium
is half duplex, that feature must be "hidden" from PPP by some lower
level mechanism, as PPP doesn't know anything about "transmit" and
"receive" modes. But this is what a standard AX25 TNC does -- it
controls the T/R state of the channel and presents a full duplex
interface to the terminal. The TNC can accept characters for
transmission from the terminal at any time, up to its internal
buffering limit, even when it is delivering received characters to the
terminal.
So there should be no problem at all in running PPP across a TNC.
Phil
------------------------------
Date: Wed, 4 Sep 1996 15:58:56 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Subject: PPP/SLIP in connected AX25?
>Seems to me it wouldn't be too hard to modify the TNC code so that it
>has a 'PPP' mode, a transparent mode where the PPP framing character
>would force sending of the buffer (including the framing chars) but only
>if the buffer contained more than just the framing char. That would be
>a nice touch. Maybe Paccomm could add that as an option mode to their
>TNC - call it the "Internet compatability mode". Sell a million upgrades.
I don't see much of a benefit here over using the existing timer
mechanism to hold off sending a non-full packet as long as characters
continue to arrive at some minimum rate. Since most PPP/SLIP hosts send
their packets with the characters in back-to-back bursts, this is really
all you need.
Phil
------------------------------
Date: Wed, 4 Sep 1996 16:33:31 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Subject: PPP/SLIP in connected AX25?
>You get nasty timing effects. I've done PPP over TCP tunnels and
>they have similar properties to an AX.25 tunnel and don't work
>well. Framing in UDP the same size as the PPP frame is far faster
TCP and AX.25 TNCs do not necessarily behave the same here.
If a local TCP or AX.25 transport module can be fed a complete burst
in an atomic transaction through a write() call with an explicit
length parameter, no problem. But because we're talking about a
character stream over a serial link, other factors come into play
because the transport module doesn't know in advance how many
characters are being sent.
In particular, TCP has the Nagle algorithm. If it is fed a stream of
characters one character at a time, you'll get the characteristic
"1/remainder" sequence of packets on the Internet. This is undesirable
if you try to send a PPP stream over a Telnet/TCP connection.
A AX.25 pad, on the other hand, generally has an inter-character timer
that buffers characters for transmission until there's a pause. If
this timer is set properly, a burst of single-character writes to an
AX.25 pad will go out in a single AX.25 frame.
I hasten to add that these differences are not due to the TCP and
AX.25 protocols themselves, but to the way they are generally
implemented. X.25 (the original inspiration for AX.25) is most often
used in a PAD with an asynch port, and the terminal connected to the
asynch port is (was) frequently a computer sending streams of data.
And X.25 networks, dating from the mid 1970s, often had slow and
expensive links. So packetizing efficiency here was very important,
so a fairly complex terminal server packetizing function was defined,
including the timeout feature, along with the X.3/X.28/X.29 protocols
to control them.
Though TCP/IP is also occasionally used in PAD mode (e.g., in a dialup
terminal server like an Annex) it is much more commonly used in a
host-to-host mode. And even when it is implemented in a terminal
server, the option is usually available to put the port into PPP/SLIP
mode (thus bypassing TCP) when the "terminal" connected to the serial
port is a computer capable of running TCP/IP itself. And most IP
networks have much faster links than X.25 networks. So the Telnet/TCP
packetization algorithms were never heavily optimized in the way that
X.25 PADs were.
Phil
------------------------------
Date: Wed, 4 Sep 1996 17:38:52 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Subject: Radio Links and AX.25 backoff
>Has anyone given any thought to a suitable protocol for T1 and faster
>speeds? AX.25 really doesn't cut it any more, we are going to have
>to be able to look for callsigns or other MAC address in hardware.
>Anyone have any suggestions?
Nonsense. All you need is a little hardware buffering. Everything else
can still be done in software running on fast modern CPUs.
To give you an idea of what can be done in software on modern CPUs,
some months ago I did an asm version of DES that can saturate a 10 Mb
Ethernet from a Pentium. Most people would consider DES to be a pretty
CPU-intensive function.
More recently I've been tuning an even more CPU-intensive function, a
Viterbi decoder. I've got it running at 250 kb/s on a P133. There's
room for further improvement if I switch from C to assembler.
Compared to these intensive CPU-crunching operations (e.g., the
Viterbi decoder performs 64 primitive add-compare-select operations on
every data bit), link protocol operations like searching for MAC
addresses and computing CRCs with table lookups seem downright
trivial.
Phil
------------------------------
End of TCP-Group Digest V96 #182
******************************
You can send your message for this bulletin
to: tcp-group@pa2aga on .AMPR.ORG-net
or: tcpaga@pi8vnw.#zh2.nld.eu on BBS-net
------
NOT TO: pa2aga@pa2aga or pa2aga@pi8vnw.#zh2.nld.eu PLEASE!!
It will get posted automatically within a few days
Read previous mail | Read next mail
| |
