| |
PA2AGA > TCPDIG 08.01.98 00:39l 202 Lines 7315 Bytes #-10109 (0) @ EU
BID : TCP_98_2A
Read: GUEST
Subj: TCP-Group Digest 98/2A
Path: DB0AAB<DB0SL<DB0RGB<DB0MAK<DB0ERF<DB0HSK<PI8DRS<PI8DAZ<PI8GCB<PI8HGL<
PI8VAD<PI8VNW
Sent: 980107/1906Z @:PI8VNW.#ZH2.NLD.EU #:6912 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA375 ; Wed, 07 Jan 98 18:14:46 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.65/7.1) with SMTP
id AA00005801 ; Wed, 07 Jan 98 19:07:29 MET
Date: Wed, 07 Jan 98 19:05:13 MET
Message-Id: <tcp_98_2A>
From: pa2aga
To: tcp_broadcast@pa2aga
Subject: TCP-Group Digest 98/2A
X-BBS-Msg-Type: B
TCP-Group Digest Wed, 7 Jan 98 Volume 98 : Issue 2
Today's Topics:
[Fwd: TCP/IP over radio] (2 msgs)
IP address coordinator mailing list
TCP/IP over AX.25 on a wearable ?
TCP/IP over radio (3 msgs)
Wireless WearComp
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/2
----------------------------------------------------------------------
Date: Tue, 06 Jan 1998 10:55:09 -0500
From: Matt Ettus <mne@andrew.cmu.edu>
Subject: [Fwd: TCP/IP over radio]
This is a multi-part message in MIME format.
--------------A8A9C86D1646251BCB0AEAD9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--------------A8A9C86D1646251BCB0AEAD9
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <34B1D394.F482708A@andrew.cmu.edu>
Date: Tue, 06 Jan 1998 01:47:48 -0500
From: Matt Ettus <mne@andrew.cmu.edu>
Organization: CMU
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i686)
MIME-Version: 1.0
To: David Mackay <David@cajun.demon.co.uk>
Subject: Re: TCP/IP over radio
References: <884085472snx@cajun.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The author of that paper missed a couple of key points:
Exponential backoff is necessary to avoid congestion-collapse.
Otherwise a congested network gets zero throughput.
VC mode doubles the number of transmitted packets, adding to
congestion, compounding the first point.
The examples used are contrived. Communication is basically impossible
if link probabilities are <80%.
In a properly designed (i.e. routed) network, congestion (collisions)
is what is causing packet loss, not poor link margins. In this case, VC
only will cause more congestion. Since there is no exponential backoff
in AX25, the network will have congestion collapse. TCP/IP will have
backoff, and all stations will share the network fairly.
Most (if not all) of the examples of commercial wireless networks
listed as VC examples are NOT mult-hop. They are cellular-based. This
also has the effect that tje base stations are never stomped on, only
the mobiles.
Matt Ettus
mne@cmu.edu
--------------A8A9C86D1646251BCB0AEAD9--
------------------------------
Date: Wed, 07 Jan 98 04:56:00 -0000
From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow)
Subject: [Fwd: TCP/IP over radio]
Matt Ettus wrote in a message to Mike Bilow:
ME> Exponential backoff is necessary to avoid congestion-collapse.
ME> Otherwise a congested network gets zero throughput.
This is not necessarily true. Even if true, it is certainly not obvious.
ME> The examples used are contrived. Communication is basically
ME> impossible if link probabilities are <80%.
I don't see this. Bad links are a technical challenge to be solved by means
that require a degree of innovation. I understand that you are thinking about
the basic idea that, in a chain where each link has probability of success p,
then a chain of n links will have probability of success p**n (p to the n
power). In as little as 6 links, for example, a 0.80 link probability turns
into a 0.26 end-to-end probability.
What motivates the desire to use VC mode in the first place is to improve link
probabilities at the expense of time, usually large amounts of time. Of
course
we need to look at improvements to the physical layer and the adoption of
error-correcting protocols, but these alone are not going to make the enormous
dents in link probabilities that are needed.
ME> In a properly designed (i.e. routed) network, congestion
ME> (collisions) is what is causing packet loss, not poor link
ME> margins.
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.
ME> In this case, VC only will cause more congestion. Since there
ME> is no exponential backoff in AX25, the network will have
ME> congestion collapse. TCP/IP will have backoff, and all
ME> stations will share the network fairly.
Exponential backoff assumes that loss is a result of congestion, for which it
is the textbook remedy. However, even Ethernet has carrier sensing and
collision detection, but we are not going to get that without migrating to
spread spectrum or similar techniques. In our case, where congestion is not
the real culprit, exponential backoff will just result in a network so slow as
to be useless. (On the other hand, as Phil and others have pointed out,
exponential backoff would be a good idea if the network improved to the state
where most loss was a result of congestion.)
-- Mike
------------------------------
Date: Wed, 7 Jan 1998 02:19:16 utc
From: emayler@juno.com (Eugene R. Mayler)
Subject: IP address coordinator mailing list
Hi Guys,
I seem to remember seeing somewhere that there is an IP address
coordinator mailing list. Is there one or has my memory failed me again?
73,
Gene Mayler - K8EE
>.
Internet: emayler@juno.com
AmPRNet: k8ee@clevsw.ampr.org
PBBS: K8EE@K8EE.#NEOH.OH.USA.NA
------------------------------
Date: Wed, 07 Jan 1998 17:35:41 +1100
From: Terry Dawson <terry@perf.no.itg.telstra.com.au>
Subject: TCP/IP over AX.25 on a wearable ?
Darxus wrote:
> now I ask my question and snow how little I know about packet radio: can
> the equipment necessary to do AX.25 be built into a wearable computer --
> is it small enough, and does it require little enough power to run off of
> batteries ?
To answer your question more directly. Yes, but it depends a great deal
on what you are hoping to achieve in terms of speed/range between hosts.
You could run something like 1200/4800/9600/19200 bps from a fairly simple
purpose built FM/FSK transceiver. Such creatures already exist for amateur
radio purposes (read: if you have an appropriate license):
Check the Tekk data radio at http://www.paccomm.com/tekk.html
These devices are only a couple of Watts, so would be fairly managable
from Gel cells or whatever, and the antenna could be made fairly small.
The Linux soundmodem driver will drive these directly at 9600 bps.
regards
Terry
--
Linux: standard and fully integrated support for Amateur Radio protocols
"Penguinitis is contagious". http://www.linux.org.au/
To be continued in digest: tcp_98_2B
Read previous mail | Read next mail
| |
