| |
PA2AGA > TCPDIG 07.01.98 02:02l 143 Lines 7069 Bytes #-10110 (0) @ EU
BID : TCP_98_1B
Read: GUEST
Subj: TCP-Group Digest 98/1B
Path: DB0AAB<DB0SL<DB0RGB<OK0PPL<OK0PHL<OK0PBB<OK0PAB<HA5OB<HA3PG<OH7RBA<
PE0MAR<PI8VNW
Sent: 980106/1849Z @:PI8VNW.#ZH2.NLD.EU #:6121 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA320 ; Tue, 06 Jan 98 18:17:13 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.65/7.1) with SMTP
id AA00005783 ; Tue, 06 Jan 98 18:56:19 MET
Date: Tue, 06 Jan 98 18:51:25 MET
Message-Id: <tcp_98_1B>
From: pa2aga
To: tcp_broadcast@pa2aga
Subject: TCP-Group Digest 98/1B
X-BBS-Msg-Type: B
an ACK. It therefore passes another copy of the first packet to the ax25
layer. This is stacked behind the first copy in the ax25 queue and now must
also be sent. Thus 2 copies of the same packet must be sent by the ax25
layer. On the poor channel this increases the traffic without any gain thus
making the delays even longer. The TCP layer may issue yet another retry
thus the problem gets worse. The TCP backoff facility should help eventually
by slowing the rate at which the TCP layer issues retries. However backoff
takes time to do this and in some versions of NOS (eg. WNOS) the backoff
doesn't backoff enough (4 * initial rtt) to be effective.
Paknet - Developed by Racal uses straight VC mode X25 (almost AX25)
Modacom - This is a German Public radio data network. Developed by
by Motorola it uses a protocol known as Radio Data - Link
Access Protocol. RD-LAP uses VC mode with a maxframe of 1
set at 512 bytes. It includes Forward Error Correction and
a very effective contention control procedure.
Mobitex - Developed by Ericsson and operational in the UK, USA, Australia
France, Belgium etc etc....This uses X25 but with a different
link layer coding to AX25. It includes Forward Error Correction
and a virtual circuit connection at the link layer.
CDPD - Cellular Digital Packet Data or CDPD. This is a packet data system
designed to add high speed packet data to the American ANALOG
Cellular Telephone system. CDPD sets in parallel with the cellular
system sharing the base stations power supplies etc. of the voice
network. Its transport protocol is TCP/IP. !!!. At its radio link
layer it uses very high levels of Forward Error Correction and a
very effective anti contention procedure. It is 2 frequency duplex.
Therefore on its Base to mobile channel where the Base station is
the only transmitter active it uses DG mode. On the mobile to base
channel where there is the potential for more than 1 mobile to
transmit at the same time. Even though a very effective anti
collision procedure is adopted, VC mode is still used. CDPD is the
nearest commercial equivilent to our attempts to put TCP/IP over
amateur packet radio.
As can be seen from the above in systems which have much more effective
channel access procedures for use on radio than CSMA VC mode is still the
mode of choice. I believe the reason for this is because radio is simply
not reliable enough for DG to be effective.
Please do not forget that a network based on DG mode is a network of
digipeaters. It didn't work in the early days of packet radio and I do not
believe it will work now.
6, A Datagrams chance of success.
---------------------------------
A datagram goes from A to D ------->>>>
--------------------------- ---------
||------>||------>||------>||
| A|| B|| C|| D|
||<------||<------||<------||
||||||||
------------------------------------
.85 .73 .72
The figures are the probability of success across each hop:
A packet sent from A to D in a DG based network has a 44% (.85*.73*.72*100)
chance of arriving. However the ACK from D must come back over the same route
so only 22% of packets will get ACK'ed successfully. Thus to sent a 5K file
infact 22.5K of data must be sent from A to ensure D gets it. All this data
must be sent by every station in the link. Even if the links are 90%
successful the packets are 72% likely to arrive the ACKs a further 72% likely
to arrive thus only 53% will be ACK'ed correctly.
I do not believe we can build a network on this basis .
Consider a VC based system. The packets are 100% likely (normally) to arrive
the link will just appear to get slower or faster depending on the hop by
hop retries. The amount of data sent will be the same as above but not sent
across all links only retried at the difficult bits. The NET/ROM'ers have
known the benefits of hop by hop ACKs for a long time maybe we need to
consider them too !!. BUT what about the problem of the TCP layer retrying
to
quickly and stacking up lots of unrequired TCP retries in the ax25 queue.
In Germany they deceided that since their whole network was VC based they
would make the TCP retry timer very very long. Thus all the retries are
generally at the ax25 layer and the multiple retries problem goes away.
I should point out this works !!. As many of you will know the packet network
in Germany is much faster than in the UK.
However if you have a mixed VC, DG network if the TCP retry timer is set very
long when your packet arrives at a DG link and is lost it will
take a long time before the TCP layer trys again. This attempt must go all
along the VC to once again take its chances on the DG bit. If it is lost
again the TCP retry timer is backing off all the time thus the delays get
worse and worse. It is also said that in a mainly DG system in which a packet
arrives at a VC link this will block quickly. This is true an is a further
example of the 2 layer retries problem previously outlined. Hoever to
conclude that therefore we must all use DG is wrong and does not take enough
account of the problems of CSMA and radio transmission paths.
So we have two problems with using VC mode. If the TCP retry timer is too
short we stack up lots of useless retries. If its too long and a DG link
is used along the way the link will get very very slow.
In summary I believe a DG only based Network cannot work well because packet
radio is too harsh and slow for this to function over more than 4 or 5 hops.
A national network will have many more hops than this so in the end there
will always be a range problem. Put clearly we will never get a national
network with full pan UK connectivity if we try and do it with DG mode on all
links. If we wish to continue operating as a number of local groups without
long range connections then a DG only approach would work very well.
High speed short distance bulk transfer will work well. Long distance may well
not work at all. Many people may suggest that they have a DG based network and
it does work well. But is this really doing live end to end linking or really
passing smtp and nntp on a hop by hop store and forward basis. If it is the
latter it is really a VC based system disguised as a DG network !!!!.
If we try VC mode I do not beleive this can work either unless every link is
VC. It would need to be agreed nationally that VC would be adopted universally
and the TCP retry timer set quite high before being allowed to find its
natural value for the link.
*** Is there any chance of national agreement ??. ***
To be continued in digest: tcp_98_1C
Read previous mail | Read next mail
| |
