| |
PA2AGA > TCPDIG 07.01.98 01:56l 157 Lines 6625 Bytes #-10110 (0) @ EU
BID : TCP_98_1C
Read: GUEST
Subj: TCP-Group Digest 98/1C
Path: DB0AAB<DB0SL<DB0RGB<OK0PPL<OK0PHL<OK0PBB<OK0PAB<HA5OB<HA3PG<OH7RBA<
PE0MAR<PI8VNW
Sent: 980106/1847Z @:PI8VNW.#ZH2.NLD.EU #:6118 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA324 ; Tue, 06 Jan 98 18:32:34 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.65/7.1) with SMTP
id AA00005792 ; Tue, 06 Jan 98 18:57:02 MET
Date: Tue, 06 Jan 98 18:51:29 MET
Message-Id: <tcp_98_1C>
From: pa2aga
To: tcp_broadcast@pa2aga
Subject: TCP-Group Digest 98/1C
X-BBS-Msg-Type: B
This would limit the capability of the system to handle large data
transfer on short high capacity links.
My suggestion to solve this is as follows:
The G6WPJ network design.
-------------------------
The main data flow at present is between a hub and its users. This
link is normally point to point and quite short and error free.
This carries lots of data (mail news ftp etc....) It can therefore work
well in DG mode. Other links from the hub should in order to be sure to
deliver its users data correctly run VC. Thus the bulk of traffic
on user access channels can still run using DG but any "network" traffic
will have the advantage of perfect delivery. Some of the problems with a
mixed system will be removed because all trunk links will work VC. If X1J
routers are used these links can share capacity with the NET/ROM based
systems (I am suggesting here IP sent VC in paralell with NET/ROM not
encapsulated in NET/ROM which is a different thing). If the TCP retry
timer is set to a fairly high value, on the short distance DG link it
will soon reduce to a proper value for the fast link but at the same
time not generate too many retries on the VC mode links. Certainly the
NOS's maintain a different retry timer for each host they connect to.
Finally to prevent congesion we need to ensure that all trunk links are
fast enough to run VC and clear the traffic being fed into them without
blocking.
This is shown below.
System Trunk
+-------------------------------+
| 19200 bits|
---------- -----------
| Link | | Link |
| | | |
---------- -----------
| | | |
HUB------ ------HUB HUB------- --------HUB
| 9600 | | 9600 |
| | | |
USERSUSERS USERS USERS
The speeds are only for example. The model assumes that users access the
hub at 9600 in DG mode and since local traffic makes up the bulk of the
hubs packet load the fact that it links to a link site at the same speed
is not be a problem. However the system trunk must be faster in order to
not get congested in times of high region to region activity. All but
the user<->hub link runs VC. I know this seems obvious but how many
systems do you know that try to link regions together at the same speed
as user access links. In this system the TCP retry timer is set quite
high and then works its way down to the ideal value for the link in
question.
Of course this is a compromise but I think it does produce a working
system using current hardware and software. The real problem to solve is
the poor performance of CSMA on radio channels because of the "hidden
nodes" problem. Solve this and you have more chance to make a DG only
system work. I have done some work on a new protocol which uses Digital
Sense Multiple Access and removes any hidden nodes. It also allows frames
of upto 3K long and has a Window size of 65535 bytes. In addition it
offers full Forward Error Correction and 19200 KBits/sec in 25KHz channels.
Its hardware and software implementation could be easily done in a Z80
based TNC similar to but not compatible with the TNC2. If anyone is
interested I will be happy to present this at the next UKIP meeting.
73 de Matt in Halstead Essex. {JO01hw}
* * *
--David
------------------------------
Date: Tue, 6 Jan 1998 10:17:33 +0000 (GMT)
From: Alan Cox <alan@cymru.net>
Subject: TCP/IP over radio
> forgiven for including below an article by Matt G6WPJ
> and inviting your valued comments.
There are several fairly broken assumptions in this IMHO. The first one
is that tcp acks pile up. Thats only the case if the AX.25 layer isnt
feeding flow control information back to a TCP layer that can handle it.
The error analysis also doesnt seem to cover the relative packet loss rates
caused by the vastly higher number of RR frames and contention for time
slots that VC mode causes. On any busy network (and 1200 baud comedy
networks are congested the moment somone starts using them) these are
significant. As the user count rises they become the dominating performance
item.
> encapsulated in NET/ROM which is a different thing). If the TCP retry
> timer is set to a fairly high value, on the short distance DG link it
> will soon reduce to a proper value for the fast link but at the same
There are "correct" procedures for setting TCP retry timers. The 3 second
default is a bit ott for amateur radio but there is stuff some folks use
where you build initial rtt estimates and store them in the routing
table. That should have the desired result automatically (not that the
manual approach is wrong if everyone actually remembered it)
> system using current hardware and software. The real problem to solve is
> the poor performance of CSMA on radio channels because of the "hidden
> nodes" problem. Solve this and you have more chance to make a DG only
It isnt just hidden node. Theres a significant amount of collision
potential just in the tx/rx turnaround times. For hub-hub links there should
be no congestion as they should be on microwave links or quiet frequencies
and with extremely directional antennae. Full duplex is a huge win too.
> system work. I have done some work on a new protocol which uses Digital
> Sense Multiple Access and removes any hidden nodes. It also allows frames
> of upto 3K long and has a Window size of 65535 bytes. In addition it
> offers full Forward Error Correction and 19200 KBits/sec in 25KHz channels.
> Its hardware and software implementation could be easily done in a Z80
> based TNC similar to but not compatible with the TNC2. If anyone is
> interested I will be happy to present this at the next UKIP meeting.
I wouldnt be at UKIP but this bit is interesting - regardless of any
flaws in the original reasoning if you can pull off a superior protocol
and squash it into a TNC2 (why oh why is this still a requirement for
amateur protocols) then its definite progress anyway.
VC is not the answer however, DG mode with FEC to bring the errors down
to < 1% per hop hub-hub is the answer. This sounds quite a step towards it
Alan
------------------------------
End of TCP-Group Digest V98 #1
******************************
Read previous mail | Read next mail
| |
