| |
PA2AGA > TCPDIG 06.01.98 23:51l 150 Lines 7076 Bytes #-10110 (0) @ EU
BID : TCP_98_1A
Read: GUEST
Subj: TCP-Group Digest 98/1A
Path: DB0AAB<DB0PV<DB0MAK<DB0ERF<DB0HSK<PI8DRS<DB0PKE<DB0SM<PI8DAZ<PI8APD<
PI8WNO<PI8GCB<PI8MBQ<PI8VNW
Sent: 980106/1845Z @:PI8VNW.#ZH2.NLD.EU #:6117 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA322 ; Tue, 06 Jan 98 18:24:43 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.65/7.1) with SMTP
id AA00005789 ; Tue, 06 Jan 98 18:56:46 MET
Date: Tue, 06 Jan 98 18:51:19 MET
Message-Id: <tcp_98_1A>
From: pa2aga
To: tcp_broadcast@pa2aga
Subject: TCP-Group Digest 98/1A
X-BBS-Msg-Type: B
TCP-Group Digest Tue, 6 Jan 98 Volume 98 : Issue 1
Today's Topics:
TCP/IP over radio (2 msgs)
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.
Loop-Detect: TCP-Group:98/1
----------------------------------------------------------------------
Date: Tue, 06 Jan 98 04:17:52 GMT
From: David@cajun.demon.co.uk (David Mackay)
Subject: TCP/IP over radio
In the hope that this group can help progress, may I be
forgiven for including below an article by Matt G6WPJ
and inviting your valued comments.
* * *
The following paper is an attempt to create a reasoned debate on the use of
connected mode or unconnected mode ax25 for transfering tcp/ip packet data.
1, The Problem.
---------------
For the benefit of any reader not familiar with the issues it is worth
outlining the problem so we can at least have an informed debate. The
picture which needs to be understood is the flow of data through a number
of software layers.
This can be drawn as below.
IN >-------+ +----> OUT
| |
| |
----------------- -----------------
| | | |
| TCP LAYER | | TCP LAYER |
| | | |
----------------- -----------------
| |
| |
----------------- -----------------
| | | |
| AX25 LAYER | | AX25 LAYER |
| | | |
----------------- -----------------
| |
| |
----------------> >--------
Sending station (ATx) Receiving station (ZRx)
Information for transfer from an application on Atx is sent to the tcp layer
for transmission. It is sent only once. The application assumes that the tcp
layer WILL deliver the data sucessfully and in the same order as the
information was sent to the TCP layer. In a working system this data is
passed by the TCP layer to the ax25 layer and forwarded over the radio
channel. Once received by the ax25 layer at ZRx it is passed up to the TCP
layer and from there to the application on the receiving station. If the
2 systems were doing an ftp file transfer for example the appliction on ATx
would be the ftp server and on ZRx the ftp client.
It should be noted that between the ax25 layer and the TCP layer there
is the IP layer however its effects are ignored for the purpose of this
paper.
The debate about Datagram (DG) verses Virtual Circuit (VC) mode is concerned
with how the ax25 layer handles the transmission of data between the 2 radio
stations.
In datagram (DG) mode the ax25 performs only a limited function. It takes the
TCP/IP frame and adds some flag bytes, ax25 callsigns, control bits and a
Frame Checking Sequence to the data. It then sends this information. It does
not setup a ax25 connection to the destination and takes no account of if the
data arrived in tact or not. The timing of any retries is only controlled by
the TCP layer. The timing of the retries is controlled in TCP by a system
known as "Backoff". The first retry will go after x secs. x can be any number
but maybe typically 7 secs. If this is not sucessfull the next retry will go
after 14 secs, then 28, then 56, then 112 and so on. It can be seen that very
quickly the station is only trying once every 2 mins. In packet radio this is
a long wait between each packet retry.
In Virtual Circuit (VC) mode the ax25 has much more to do.
It takes the data from the TCP layer and attempts to deliver it and get
a confirmation that it has indeed delivered it. It does this for any packet
passed to it by the TCP layer regardless of if this is the first go at sending
it or a TCP layer retry of data already sent. In attempting to deliver the
data the ax25 sets up an ax25 connect and then sends the data. It looks for
ACKs to check the data has been received correctly and retries the data if it
does not get any ACKs. Thus in VC mode 2 layers of protocol are sending
retries. The ax25 retries are on a hop by hop basis. The TCP retries are on
an end to end basis. In the case above this is the same thing. But in a
network involving 2 stations connected via another system the ax25 will still
ack hop by hop while the TCP layer will ack end to end. This is similar to a
NET/ROM connection.
3, Why Virtual Circuit mode ?
-----------------------------
This is as used for all non tcp/ip packet activity so it can
be shown to work. VC while having a small amount of overhead is much more
reliable. By doing hop by hop acks continually trying on a bad channel until
it gets through it is a much more effective delivery service. Of course all
the ax25 NET/ROM based networks are essentially a VC based system but with
NET/ROM replacing the TCP layer in our diagram above. It has the advantage
that because it is the same as native ax25 (just the data contained in the
packet is different) it becomes no problem to share the channel with other
ax25 users. The maxframe limit of 7 is as described above a limit to its
data throughput on fast link systems. The other big problem with VC is the
fact that 2 layers of protocol are both doing retries.
4, The 2 layer retries problem.
-------------------------------
The 2 layer retries problem can be described as follows:
ATz is trying to send its first packet to ZRx using VC mode. The TCP layer
at ATz asks the ax25 layer to send its first packet to ZRx. The channel is
busy or the link is bad so the ax25 layer at ATx has to retry several times.
In the meantime the TCP layer has seen the retry time go by without getting
To be continued in digest: tcp_98_1B
Read previous mail | Read next mail
| |
