| |
PA2AGA > TCPDIG 14.01.98 02:13l 138 Lines 5335 Bytes #-10102 (0) @ EU
BID : TCP_98_6A
Read: GUEST
Subj: TCP-Group Digest 98/6A
Path: DB0AAB<DB0SL<DB0RGB<DB0ABH<DB0SRS<DB0AIS<DB0GV<DB0EAM<DB0SGL<DB0END<
DB0ACC<PI8DRS<PI8DAZ<PI8GCB<PI8WNO<PI8VAD<PI8VNW
Sent: 980113/2207Z @:PI8VNW.#ZH2.NLD.EU #:11731 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA752 ; Tue, 13 Jan 98 21:15:12 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.65/7.1) with SMTP
id AA00006068 ; Tue, 13 Jan 98 20:50:02 MET
Date: Tue, 13 Jan 98 20:42:10 MET
Message-Id: <tcp_98_6A>
From: pa2aga
To: tcp_broadcast@pa2aga
Subject: TCP-Group Digest 98/6A
X-BBS-Msg-Type: B
TCP-Group Digest Tue, 13 Jan 98 Volume 98 : Issue 6
Today's Topics:
[Fwd: TCP/IP over radio]
DNS
TCP/IP - suggestion for new L2 protocol
TCP/IP over radio
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/6
----------------------------------------------------------------------
Date: Sat, 10 Jan 1998 16:09:44 +1100
From: Mark Aitken <vk3jma@ozemail.com.au>
Subject: [Fwd: TCP/IP over radio]
At 04:56 am 7/01/98 -0000, Mike Bilow wrote:
>
>I disagree. The textbook models do not account for some of our inherent
>problems, particularly hidden transmitters. This is what has motivated the
>research with token-passing protocols, DAMA, and so on.
>
I actually think it is a shame that not more is done about DAMA Master &
Slave here in VKland, as the small amount I understand about DAMA shows it
to be a much better alternative on our slow congested 1200 baud links using
CSMA.
Mark
------------------------------
Date: Mon, 12 Jan 1998 19:19:51 -0800 (PST)
From: Brian Kantor <brian@karoshi.ucsd.edu>
Subject: DNS
There appears to have been some damage to the AMPR.ORG database due to
a program fault. I believe I've repaired the problem, but it might be
wise to check your entry in the Domain Name Service to make sure that
nothing was omitted (and add it back in if needed).
- Brian
------------------------------
Date: Mon, 12 Jan 1998 22:46:58 +0000
From: "Jens David" <dg1kjd@dg1kjd-svr.ampr.org>
Subject: TCP/IP - suggestion for new L2 protocol
Hi all,
it was very interesting for me to read David's excellent report and
the followups. I'd like to summ up our results:
There are currenty two different modes of operation for sending IP
packets over amateur radio AX.25 links:
1.) "DATAGRAM" mode
The IP frame is encapsulated in an AX25 "unproto" (UI) frame.
Advantage:
- Low protocol overhead, no unneccessary retransmissions on L2.
- No congestions caused by low window sizes (max 7 frames in AX25
V2.2)
Disadvantages:
- Higher protocol levels (namely TCP) have to do excessive error
correction/retransmissions to a degree they were not designed for and
obviously can't cope with because amprnet interlinks suffer from high
BERs and packet loss.
- No means of doing packet fragmentation on L2
- Because there's no retransmission on L2 it's not possible to
implement a hop-to-hop technique for forwarding frames which leads to
even higher packet loss rates over multiple-hop paths.
2.) Virtual Circuit ("VC") mode
Advantages:
- By using AX25's own error correction/retransmission algorithms a
very effective, fast and reliable means of trasport for IP frames is
given, thus improving TCP throughput on ham links with high BER
and packet loss rates.
- By implementing HOP-2-HOP techniques retransmission overhead and
packet loss probability on multi-hop paths can be minimized.
Disadvantages:
- AX25 implements no method of congestion control and by providing a
nearly error-free tunnel between source and destination it leaves no
way of recognizing a congested network path to TCP, thus causing even
more aggressive retransmissions and congestions.
- Small RX/TX window sizes at 7 frames of 256 bytes cause congestions
at high-speed (at least half-duplex) ROUTERS and hosts.
- High protocol overhead contributing to load of interlinks
The solution to all this seems quite obvious:
We need a new - or at least heavily modified - L2 protocol. At the
time AX.25 was designed its idea was taken from X.25, a data link
protocol still excessively used in different "virtual" (?) WAN
networks. Its means of error correction are not sufficient for
today's HAM links suffering from point-to-multipoint connections with
hidden station problems or interlinks with high packet loss.
Taking all these points into cosideration, I'd like to pose the
following suggestions:
- We need a "lighter" error correction, providing a good throughput
with few retransmissions. How about implementing a
Reed-Solomon-like EEC algorithmon as an option on the new L2
protocol? Options could be negotiated on link setup.
- Selective packet reject and larger windows.
Commercial X.25-like protocols have been working with a modulo of 128
packets since ages. A similar specification by PE1CHL exists for the
AX25 protocol, but to my knowledge nearly no modern AX.25 protocol
To be continued in digest: tcp_98_6B
Read previous mail | Read next mail
| |
