OpenBCM V1.08-3-g9b42 (Linux)

Packet Radio Mailbox

HB9ON

[OpenBCM Lugano JN46LA]

 Login: GUEST





  
N1URO  > NODES    21.01.21 11:15z 75 Lines 4431 Bytes #999 (0) @ WW
BID : 59358_N1URO
Read: GUEST
Subj: FlexNet vs NetRom
Path: HB9ON<IW2OHX<IR1UAW<IQ5KG<I0OJJ<EA2RCF<OK2PEN<N1URO
Sent: 210121/1106Z @:N1URO.#CCT.CT.USA.NOAM #:59358 [Unionville] $:59358_N1URO

Greetings;
Years ago there was a group called NEDA (NorthEast Digital Association) who
was excellent in their bench testing and documentation. So good at docs that
they often were written above that of those who were intended readers. There
were also two other lesser known groups that co-existed with NEDA and often
helped feed NEDA some of it's information through liason members:
EastNet and NETCPA (NorthEast TCP Association).

Back in the 90s we seemed to be pretty content with using NetRom as a 
network transport layer. It was simple to attach IP frames to for routing
IP, Aliases were easy to learn and use, and some of the guess work into
getting from point A to point E was such that you didn't need to know
points B, C, and D. Nodes were kept to an RF-Only propagation and were
respected because your neighbor demanded that respect of not flooding them
with nodes lists to retransmit out.

However, just before 2000 EastNet's K1YON was overseas on business and
brought back a copy of pc/FlexNet. EastNet's K2BJG and WB2CIK studied the
possible benefits of FlexNet and decided to get rid of the entire NetRom
network in favor of FlexNet. K1UOL's personal goal was to prevent IP on
RF as he was a firm believer (though be it quite incorrect) that IP was
a wired only routed protocol. While in most cases this is true it's not 100%
accurate in nature.

It took almost 5 years for EastNet's engineer to get IP to work under FlexNet
but once it did it was quite remarkable to watch. It gave new life to the
services we have on EastNet even at 1200 baud. Services such as web surfing,
ftp, email, telnet, etc. Pretty much, if it's text based it worked on IP
and on a multitude of platforms... and better than encapsulated under 
NetRom. Here's what we found:

In packet, standard ax.25 frames consist of a maximum transmission unit (MTU)
of 256 bytes. When NetRom is attached we lost 20 bytes per frame for protocol
overhead or 100 bytes per every 5 frames. Every frame had to receive an ACK
from NetRom so for every frame sent, an ack is required to be received or a
CHOKE frame is sent. With FlexNet, think of it as a streaming service for
packet... so in a cycle of 8 (ax.25 being an 8 bit protocol) say during
mail forwarding between BBS, FlexNet -only- needs to ack the first and LAST
frames within the stream.  If it sees as frame is missed in the middle it 
will request a resend from that frame onwards. This keeps the chatter
during high use periods low, and the efficiency high. Being a digipeater
with a built in auto router this makes it even more efficient than NetRom
in regards to routing.  1200 baud links appear as if they're 2400 baud.
9600 baud links act as if they're almost 19200 baud.

Flex uses RTTL pings and as close to "real time routing" as you can get on
RF. It is not meant per say for wired transports (which is why there's issues
with INP3 deployments in some cases). In a case of such where RTTL's are
1ms for 2 separate links, and one link begins to forward mail, the other link
will then seem to become faster - but will be a false positive.

Route information between sites is almost instant. Destinations (Flex's
equivilant to NetRom's Nodes) are shown not only in real time BUT are also
proven by auto RTTL pings to be connectable. NetRom only uses a "best guess".

We take advantage of that extra 20 bytes we gain from NetRom to use for
IP instead since there's a LOT more services on IP than there are on the
NetRom systems. Routing IP under Flex is quite tricky at best but once
you figure it out you'll notice that Flex will actually act like a crude
but effective BGP type router for IP on RF than NetRom can ever try to
accomplish. If the path breaks during mid session and there's a redundant
path available, the IP socket will simply re-establish itself on the new
path without losing the session. When NetRom's path drops, the whole
shabang drops... IP, ax.25, the works. One benefit we did incorporate
into our configuration was for those who can't fathom desti's vs nodes
we run NetRom under our IP. It's rarely used but it's there as an IP
service. Yes it gives that 20 bytes back into protocol overhead when used
but for the most part it's not even seen or used so it's a non-issue.

That's not to say we haven't run into bugs and have a very difficult
time finding support on them but for the most part it just seems to
work just fine.

---
SendBBS v1.1 by N1URO for LinFBB


Read previous mail | Read next mail


 26.04.2024 17:00:59zGo back Go up