[aprssig] RK3KKPK? (CONNECTED Igates?)

[Andre]

Op 30-1-2012 8:47, Kris Kirby schreef:
> Another writer wrote:
>> You don't even need connected packets, a few weeks ago I talked about
>> using ax-udp, the backbone that these wormholes use, to transport ui
>> frames from one gate or station to another gate or station, current
>> software that I used does not yet gate on destination, only on it's
>> own call tho it can gate on generic calls as wel but that would create
>> a mess. It can be rewritten to gate on MH for destination call.
>> DigiNed the software I used is afterall opensource and can transport
>> both ui-frames and connected frames. In europe there is another
>> automatic routing system active called flexnet, you select the local
>> node as the first digi, the remote node as second digi and the nodes
>> will so hop to hop acknowladge and best routing for every packet so it
>> can change from one moment to the other without the user realising it,
>> offcourse this is designed for RF use and does not flood like my
>> aprs-udp idea did. another interesting note is that flexnet does do mh
>> routing once you get to the remote node, it looks what port the user
>> is on and downlinks on that.
> In the commercial satellite space, they have "protocol gateways" that do
> horrible things to packets in the name of keeping the traffic flowing
> despite the delays. TCP/IP is designed to retransmit by itself; AX.25
> connected frames are the same in that regard. There's no need to
> re-transmit a packet if another layer is handling that function. OTOH,
> the packet length of a 1200 BPS half-duplex packet radio system maxes
> out at 255, which is significantly less than the 1500 byte MTU of
> ethernet. For short frames which can be fully encapsulated, something
> like AX-UDP makes a lot of sense. It's when you cross the payload
> barrier and go into the next packet that you start buffering and
> splitting packets and reassembling them. Of course, IPv6 doesn't make
> this any easier, with even LARGER amounts of address space (and headers)
> and BIGGER packet sizes, so we need to come up with something to allow
> us to fit one protocol over another.
>
> I think we're at a precipice where we can build a protocol gateway of
> sorts or find a way to
>
> a) segment larger packets into smaller payloads for air transit or
> b) let the next layer up deal with it and keep using UI frames.
ip over ax25 does that already just use datagram mode rather then 
virtual cirquit mode, datagram mode encapsels in UI frames and the 
ip/ax25 protocoll handles the fragmentation, the only downside of ip 
over ax25 is that tcp/ip was never designed for slow links, even on 9k6 
at can stall and die after a few retransmits because tcp/ip backs off 
the time between restransmitting.
> I don't see any reason to involve the overhead of the Connected stream
> in the process at all. TCP/IP port numbers and development outran X.25
> and left it far, far behind. However, we're still stuck with devices in
> the middle which have little brainpower and less space left to handle
> and manipulate packets in a meaningful way.
To be fair, in datagram mode there is litle difference between 
encapseling in ethernet, DstarDD or encapseling in AX25, the only thing 
other then regulations that is making it not so usefull is speed.
> The advent of digi_ned also brings out some interesting applications.
> For instance, a remote site can be connected to the APRS network by
> bi-directionally or uni-directionally repeating either audio or data to
> a dedicated link radio for analysis or collection. Further, this link
> could be implemented using a 9600 bps FSK setup. In a place with no APRS
> coverage, a high-site could be used to fill in for pickup and the only
> active transmitter would be low power and directional away from the
> site.
Yes Digi_Ned is very flexable it can even be made to restransmit frames 
unaltered with only dupe checking governing restransmitions, very easy 
to build mesh networks that way as long as you set the dupe check longer 
then the longest roundtrip time trough the mesh, 30 seconds usualy 
should be enough but boosting it to 1 minute should be fine. It does not 
even matter what backbone you pick as long as it can encapsle ax25 frames.
> Then again, if one really wants to get nuts, we're limited by statute to
> 100KHz and 19200 baud at 222MHz and up, which when using 8-PSK or 64-QAM
> can be pushed to about a half-megabit before you start throwing bits
> away for FEC.
I have experimented with 76k8 gmsk on radios designed for wide band FM 
(broadcast qualety) we could go to 300 k theoreticly before running out 
of bandwith in the IF but the 386 JNOS machines we used in those day 
could not keep up, slovanians are regulary working 10 Mbaud using simple 
psk transmitters and scramblers, the scrambling offcourse is not 
cryptographic but rather to make sure the data stream is 'random' enough 
to sync the decoder clock.
It realy is a shame if you are realy limited to 19K2 symbol rate because 
64-QAM is not very forgiving on poor signals and needs a lot of FEC to 
stay stable in a typical ham link.
> --
> Kris Kirby, KE4AHR
> Disinformation Analyst
> Internet Plumber
> Server Sitter
>
73 Andre PE1RDW