[aprssig] Tracker Smart Pathing

[John Ronan]

Ok, this is getting rather long now apologies.

On 21 Mar 2006, at 17:43, <scott at opentrac.org> <scott at opentrac.org>  
wrote:



> I kind of like the way frame relay deals with congestion - f
>
I'd forgotten that (from my CCNA), yes it is nicely done..
>
> The AUTO alias could drop to a lower setting, like WIDE1-1, or stop
> digipeating entirely.  The AUTO thing would also only affect the  
> first digi
> to hear a packet - after that it'd be replaced with something else.
>

Thats a good point about the first digi being the only one to do the  
AUTO (or Curt's AUTOAP whichever is decided upon).  It should not  
stop digipeating entirely, as that then becomes an easy way to do a  
Denial of Service attack against the digi, be it intentional or not.

I think dropping back to WIDE1-1 is a good start.  Obviously we don't  
want to encourage Tzarist behaviour.  Right let me see.  What  would  
we (me!) like this to do

1. Pre-empt the AUTO to the current highest/best path the digi thinks  
is optimal (however this is done). With an upper bound configurable  
much like UI-DIGI is today.

2. If the user uses a WIDEn-n, then it should behave as any current  
digi (backwards compatability).

This would allow users to use WIDEn-n,AUTO or WIDEn-n, or just AUTO.

I've forgotten why but I have it in my head that it would be nice for  
these Digi's to find one another (or other digis), but I've forgotten  
why now.

>
> I'm trying to avoid that kind of complexity.  I'd prefer a more  
> elegant
> solution, that doesn't rely so much on site-specific setup.
>
Ok, fair enough, I was just thinking out loud.
>
> No problem, shouldn't take too long to write up.  I don't have a
> configuration utility for it, though - it's all in a C data structure.
> Maybe I'll get a chance to write something this weekend.

The OT2's haven't arrived yet.. so no rush :).  Hopefully I'll have  
them before the weekend.  Is the compiler for the OT2 Code free? No  
config utility would be required then.

>> fit in with NSR? I do like the idea of a DIGIs being able to
>> discover
>> each other, figure out their 'place' in the network and acting
>
> No idea.  I've read over the documents, but it hasn't really  
> 'stuck' yet.
Ok no worries

[in reply to Bob's email]
> So they don't have to use AUTO.  They can still run TRACE7-7 if  
> they really
> want to.  But if a long-haul trucker wants to run one setting and not
> generate excessive traffic, they can run maybe WIDE3-3,AUTO and  
> know that if
> they drive into an area that supports AUTO it'll knock the path  
> down to
> whatever is recommended for the area.

Exactly, thats the idea.

>
> How about using "APAUTO" in the destination field, which would be
> picked up by the smart digi and tweaked into an appropriate path?
> The "AP" would need to be there for APRS clients to attempt
> decoding, else they might think it an ALTNET call.
>
> That's seven more bytes we don't have to transmit, as we wouldn't
> need _any_ digipeaters in the path.  Of course this wouldn't work
> for Mic-E packets, but would for all other types of APRS packets.

Hmm, I don't know about Mic-E...

>
> I don't think anyone implemented directional digipeating based on
> SSID, did they?  Perhaps destination SSID can be commandeered for
> the purpose then.
I've read about it in the spec,  so this newbie hasn't a clue.

Regards
de John
EI7IG

--
John Ronan <jronan at tssg.org>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org