<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">IMO all this is ridiculous. At best it will be partially implemented and the results will be useless. Just like existing attempts at route tracing are at best unreliable, because there is no standard implementation and much of the OTA infrastructure is built on prehistoric hardware that won't get changed.</blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">K... well there's now a bunch of us building digipeaters on Cortex ARM cores or full Linux SBCs getting pretty frustrated that most of the digipeater behavior documentation out there is a list of settings for UNPROTO and BTEXT and whatever fields, which mean nothing to us youngins who have never seen a TAPR TNC2. I'm trying to move past all the prehistoric infrastructure that exists and give us a better tool to frame the future conversations on what behavior is right and which isn't.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">you DON'T punish. You don't drop a packet out of spite. If you find yourself using word like "punish", your next move will _not_ be a good network design decision.<br>Feel free to fix/truncate/rewrite it to the locally acceptable maximum hop count path.</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">So I've got you down as one vote for "Punish by reducing the requested hops to maxhop."</div><div class="gmail_extra"><br></div><div class="gmail_extra">Perhaps punish is a bad word choice. Unfortunately, the term "QoS drop" seems to also be a dirty word to many APRS elites.</div><div class="gmail_extra"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Think about an IP TTL. It will probably leave your system at 255, but the first router it passes through may drop it to 127 (I think I've seen that particular scenario). It most certainly would not be configured to drop the packet</blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">I have most certainly never seen that scenario. RFC791 let you reduce TTL by the number of seconds (LOL) it took you to process the packet, but that's the only reference to anything except for TTL = TTL - 1 that I've ever seen.</div><div class="gmail_extra"><br></div><div class="gmail_extra">It's funny that you bring up IP TTL, because comparing APRS to how the TTL field was meant to be used for multicast routing is very interesting.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">when we get a real layer 3 network instead of this inconsistent patchwork of hacks? And creating such a thing would, IMO, be _easier_ than dealing with the hacks.<br>[rant for a real APRS network deleted. check the archives, i'm sure i've made it more than once.]</blockquote><div><div data-smartmail="gmail_signature"><br></div><div data-smartmail="gmail_signature">I am well aware of your incessant ranting on the topic. I downloaded the APRSsig archives and read a large chunk of them for my thesis, so I've gotten to read your rant MANY times. I've also gotten to read many other rants on the topic in the last day in reply to my original email off-list.</div><div data-smartmail="gmail_signature"><br></div><div data-smartmail="gmail_signature">When are you guys going to start actually building something and not just discourage those of us trying to get something done? Go pick a new packet frequency and let us know when you've got a working prototype of whatever comes after APRS.</div><div data-smartmail="gmail_signature">--<br>Kenneth Finnegan<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.<wbr>com/</a></div></div>
<br><div class="gmail_quote">On Thu, Aug 25, 2016 at 7:42 AM, Jason KG4WSV <span dir="ltr"><<a href="mailto:kg4wsv@gmail.com" target="_blank">kg4wsv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Aug 24, 2016 at 7:41 PM, Kenneth Finnegan <span dir="ltr"><<a href="mailto:kennethfinnegan2007@gmail.com" target="_blank">kennethfinnegan2007@gmail.com</a><wbr>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* The two places where the preempt RR bit is documented disagree with each other. I think RR-bits.txt is correct.<br><a href="http://www.aprs.org/aprs12/preemptive-digipeating.txt" target="_blank">http://www.aprs.org/aprs12/pre<wbr>emptive-digipeating.txt</a><br><a href="http://www.aprs.org/aprs12/RR-bits.txt" target="_blank">http://www.aprs.org/aprs12/RR-<wbr>bits.txt</a></div></div></blockquote><div><br></div></span><div>IMO all this is ridiculous. At best it will be partially implemented and the results will be useless. Just like existing attempts at route tracing are at best unreliable, because there is no standard implementation and much of the OTA infrastructure is built on prehistoric hardware that won't get changed.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* How should we be punishing excessively long paths</div></div></blockquote><div> </div></span><div>you DON'T punish. You don't drop a packet out of spite. If you find yourself using word like "punish", your next move will _not_ be a good network design decision.</div><div><br></div><div>Feel free to fix/truncate/rewrite it to the locally acceptable maximum hop count path. </div><div><br></div><div>Think about an IP TTL. It will probably leave your system at 255, but the first router it passes through may drop it to 127 (I think I've seen that particular scenario). It most certainly would not be configured to drop the packet.</div><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>* When would we ever not want preemptive digipeating?</div></div></blockquote><div><br></div><div><br></div></span><div>when we get a real layer 3 network instead of this inconsistent patchwork of hacks? And creating such a thing would, IMO, be _easier_ than dealing with the hacks.</div><div><br></div><div><br></div><div>[rant for a real APRS network deleted. check the archives, i'm sure i've made it more than once.]</div></div><br><div data-smartmail="gmail_signature">-Jason<span><font color="#888888"><br>kg4wsv</font></span></div>
</div></div>
</blockquote></div><br></div></div>