[aprssig] IS-to-RF packet Weighting

[lawrence labranche]

If the current software rejects the new path attempt in a packet, then where is the harm? A rejected packet is not further processed in to the network, no? What is the difference then if a client, automatically messages a nearby rf aprs device, other than bandwidth being taken up? I don't see someone who is traveling cross country using CQSVR for all the areas they pass through. I find I monitor my Open APRS client more for messages than my radio, because it still gets messages that my radio missed for being off, etc. USB 1.1, USB 2.0, USB 3.0 are all specifications. I don't see what the big problem with working out solutions are. I thought that was one of the purposes of this group is to bring forth ideas for consideration.

I think the new path, however it is implemented as being needed. I think the reverse I gates can then decide to reject, throttle, or route biased on the path. The routing bit is to allow the traffic only on RF channels that the R-Gate person wants. the rgate should default so the path outputted over RF is 100% compatible with current standard to prevent nearby igates from putting that packet back in to IS. It would have the option of using the new path or whatever is decided. That is for those areas that have converted over, or there is no other igate. R-gates shouldn't only rely on path. They should have the tools to automatically throttle traffic should it get out of hand. HR is experimenting, and creating. Things sometimes go wrong, tools need to be in place.


New IS/IS2/Whatever server software: I don't care if it accepts new path on same or different TCP ports. I think for compatibility, should only send out the new path(etc) on new ports. Any new path details should be stripped out when talking to old clients and servers to make sure 100% compatibility. Since software will have to be changed, a serious look at security is needed.

A look at says filtered ports do not allow much traffic by default. Instead the client has to enable further functionality before the port will send additional traffic to client.

KI6ZQY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20111229/9a926e52/attachment.html>