| |
PA2AGA > HDDIG 24.03.00 09:53l 173 Lines 7424 Bytes #-9536 (0) @ EU
BID : HD_2000_83C
Read: GUEST
Subj: HamDigitalDigest 2000/83C
Path: DB0AAB<DB0SL<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0GOS<DB0PKE<DB0SM<PI8DAZ<
PI8GCB<PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 000324/0146Z @:PI8VNW.#ZH2.NLD.EU #:59077 [HvHolland] FBB7.00g24
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA31850 ; Fri, 24 Mar 00 01:08:33 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.70/7.5.3) with SMTP
id AA00018495 ; Thu, 23 Mar 2000 21:27:00 MET
Date: Thu, 23 Mar 00 21:25:16 MET
Message-Id: <hd_2000_83C>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 2000/83C
X-BBS-Msg-Type: B
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: NOS (and derivatives) don't send FRMRs ?
Hank Oredson <horedson@att.net> wrote:
>Have been considering a "node unbroadcast" extension to NET/ROM.
>i.e. if a link was "really lost", notify adjacent nodes of that fact right
>away.
>Also when a new link is discovered, do an immediate broadcast of
>that new link. The "node unbroadcast" would be a simple addition to
>the protocol using a unique tag (say 0xfe) in place of the 0xff BC ID.
>An alternate technique would be to use a different PID ...
Many NET/ROM implementations have had this for years. They use a broadcast
with quality 0 or 1 for this.
Tag FE is in wide use as a "request broadcast" indicator. When a node
starts, it sends its first (usually empty) broadcast with FE tag and
expects the neighbors to send their broadcast as a result, to quickly
fill the routing tables after a restart.
This is supported by NOS, TheNET, pe1chl-NET and others.
>Most of (all of?) the NOS ip-over-NET/ROM implementations use the
>NET/ROM equivalent of UI frames. This has the potentially adverse affect
>of bypassing NET/ROM's end-to-end flow control, and can in fact cause
>serious congestion problems if timing parameters are not carefully adjusted.
>K-net seems particularly prone to this problem, at least in version 1.0.
NET/ROM implementations need to have a "discard" type flow control whereby
they use soft and hard limits on the outgoing queue lengths. Above a
certain soft limit they can return congestion indications for connected
mode packets and should drop connectionless packets. Above the hard limit
they should discard everything.
pe1chl-NET has this, but most likely other NET/ROM implementations don't.
Stupid TCP options like "no backoff" or "linear backoff" have been built
into some versions of NOS. This is lethal in any network environment
where hop-to-hop retries exist.
>Are there ip-over-NET/ROM implementations that use NET/ROM
>connections instead of simply tossing L3 frames for NET/ROM to route?
There exists a German hack to send IP frames in normal pid-F0 packets.
It relies on packets being correctly re-assembled in the presence of
network level fragmentation. To assure this, the effective packet length
must be set very small, making it a very ineffective protocol.
(I think they recommend 88 byte MSS to have packets <= 128 bytes)
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | WWW: http://www.knoware.nl/users/rob |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
>.
------------------------------
Date: Thu, 16 Mar 2000 10:16:26 GMT
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: NOS (and derivatives) don't send FRMRs ?
Dana H. Myers K6JQ <dana@source.net> wrote:
>I'm still mildly tempted to build a pedantic flavor of AX.25 for giggles,
>maybe I can save the trouble by looking at ancient tcp-group archives?
Yes... check the archives of about a decade ago, or slightly earlier...
>> (another condition that often would lead to a FRMR in the official protocol
>> and will cause no harm when simply ignored: excessive buffering of packets,
>> e.g. in a KISS TNC, outside of the control of the AX.25 engine. this can
>> cause "long delayed packets" that arrive after a corrective action was
>> already taken)
>The relatively short sequence-number stream is certainly an issue here. X.25
>was clearly designed for relatively reliable wired circuits, and certainly
leaves
>a bit to be desired in the translation to radio circuits, even relatively
good
>ones. Old news, I know, but I've been recently reminded :-)
Do you know about the "extended sequence" option (modulo-128 numbering)
that I proposed some years ago? It has been implemented in a number of
environments, and solves these problems. Because it additionally limits
the MAXFRAME to half the sequence space, it even allows for buffering
out-of-sequence frames without ambiguity problems.
It can be found on my website.
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | WWW: http://www.knoware.nl/users/rob |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
>.
------------------------------
Date: Mon, 20 Mar 2000 10:09:14 GMT
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: NOS (and derivatives) don't send FRMRs ?
Hank Oredson <horedson@att.net> wrote:
>> Many NET/ROM implementations have had this for years. They use a broadcast
>> with quality 0 or 1 for this.
>Have never seen this. Is it immediate, or does it wait for the next
>node broadcast?
Depends on the implementation. My version just waits for the regular
broadcast, but a modified TheNet version from Belgium sends immediate
updates. However, that software has now switched to a VC between nodes
and a completely different protocol (of course only between compatible
nodes)
>I had in mind something "realtime". Played with it
>a bit and it seemed useful, at least in networks where nodes come
>and go frequently, for example users that turn off their computers,
>but still need NET/ROM connectivity to be able to route ip.
That is something that should be avoided... use a permanently available
gateway and/or combine it with the net/rom node.
(IP routing in the nodes, that is what you need)
>I like the "idea" of immediate passing of heard node broadcasts,
>but there is a large hazard of creating broadcast storms this way.
It is being done, but with large changes to the protocol.
>Am aware of this one. Did not become convinced it was useful,
>since the only time it made sense was the very first time a node
>came on air. After that first startup of a new node, it should be
>able to keep track of it's own node list and not require bootstrap
>of the node list on reboot. Once watched JNOS in a reboot loop
>cause continuous node broadcasts from three adjacent nodes.
That is not so bad as long as the links are on isolated frequencies,
which they should be. Saving your nodelist to disk is potentially much
worse. I tried this, but you will have to use a reliable timestamping
method (which was not available in those days as many of the old PC's used
at the nodes had no CMOS RTC) and/or you have to mark the loaded-from-disk
nodes in such a way that they *never* are broadcast until they are
confirmed in a neighbor node broadcast.
When you don't do this, you will see old and forgotten nodes appear and
re-appear in your list for months! Believe me, I have tried it.
So, it is better to always start up "clean" and ask the neighbors what
nodes there are.
>Right now watching K-net drop two of every four ip packets presented.
>Every time, without fail. It's not running out of buffers. Just drops 'em.
To be continued in digest: hd_2000_83D
Read previous mail | Read next mail
| |
