POLL: How do you feel about HamWAN network having shared control of the microwave modem @ your location?
Hello, Keeping the network and all client devices correctly configured is no easy feat. These are complicated devices with 100s of settings, which will need to change in coordinated ways over time. To ensure correct operation, it would make sense for the HamWAN network to push updates and change settings on end-user modems. Almost all ISPs run this way already. The difference is you can still login + control your device, but any setting changes you make which make the device non-compliant in ways HamWAN cares about would be automatically overridden with a config update from the network. If the network can't control and repair your device settings, you would lose authorization onto the network until the settings are fixed. I see this shared administration model as the only one that's feasible in keeping a reliable network running. Please let me know if you are OK with it, if you object to it, or if you have a better idea. Thanks, --Bart
Why do we need to manage end-clients in order to maintain a solid backbone? On Thu, Feb 28, 2013 at 4:16 PM, Bart Kus <me@bartk.us> wrote:
Hello,
Keeping the network and all client devices correctly configured is no easy feat. These are complicated devices with 100s of settings, which will need to change in coordinated ways over time. To ensure correct operation, it would make sense for the HamWAN network to push updates and change settings on end-user modems. Almost all ISPs run this way already. The difference is you can still login + control your device, but any setting changes you make which make the device non-compliant in ways HamWAN cares about would be automatically overridden with a config update from the network. If the network can't control and repair your device settings, you would lose authorization onto the network until the settings are fixed.
I see this shared administration model as the only one that's feasible in keeping a reliable network running.
Please let me know if you are OK with it, if you object to it, or if you have a better idea.
Thanks,
--Bart
______________________________**_________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/**mailman/listinfo/psdr_hamwan.**org<http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org>
-- Benjamin
HamWAN is not just a backbone. It's a wide-area-coverage network with its own backbone as a necessity. The health of PtP links is not at issue, but the PtMP layer is. There are many examples, but here are a few: 1) Configure the clients with the latest frequency scan lists so that they can find sites 2) Push new routes down to clients for re-announcement and usage in home networks 3) Update firmware on clients when critical problems are found --Bart On 2/28/2013 4:53 PM, Benjamin Krueger wrote:
Why do we need to manage end-clients in order to maintain a solid backbone?
On Thu, Feb 28, 2013 at 4:16 PM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
Hello,
Keeping the network and all client devices correctly configured is no easy feat. These are complicated devices with 100s of settings, which will need to change in coordinated ways over time. To ensure correct operation, it would make sense for the HamWAN network to push updates and change settings on end-user modems. Almost all ISPs run this way already. The difference is you can still login + control your device, but any setting changes you make which make the device non-compliant in ways HamWAN cares about would be automatically overridden with a config update from the network. If the network can't control and repair your device settings, you would lose authorization onto the network until the settings are fixed.
I see this shared administration model as the only one that's feasible in keeping a reliable network running.
Please let me know if you are OK with it, if you object to it, or if you have a better idea.
Thanks,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Maybe we should go over the routing infrastructure. I didn't realize we were letting client devices do any routing. That's a recipe for disaster. They should simply send packets to our sites, and we do all the routing from there. Why wouldn't we have any client nodes simply be dumb gateways for their network? On Thu, Feb 28, 2013 at 5:42 PM, Bart Kus <me@bartk.us> wrote:
HamWAN is not just a backbone. It's a wide-area-coverage network with its own backbone as a necessity. The health of PtP links is not at issue, but the PtMP layer is. There are many examples, but here are a few:
1) Configure the clients with the latest frequency scan lists so that they can find sites 2) Push new routes down to clients for re-announcement and usage in home networks 3) Update firmware on clients when critical problems are found
--Bart
On 2/28/2013 4:53 PM, Benjamin Krueger wrote:
Why do we need to manage end-clients in order to maintain a solid backbone?
On Thu, Feb 28, 2013 at 4:16 PM, Bart Kus <me@bartk.us> wrote:
Hello,
Keeping the network and all client devices correctly configured is no easy feat. These are complicated devices with 100s of settings, which will need to change in coordinated ways over time. To ensure correct operation, it would make sense for the HamWAN network to push updates and change settings on end-user modems. Almost all ISPs run this way already. The difference is you can still login + control your device, but any setting changes you make which make the device non-compliant in ways HamWAN cares about would be automatically overridden with a config update from the network. If the network can't control and repair your device settings, you would lose authorization onto the network until the settings are fixed.
I see this shared administration model as the only one that's feasible in keeping a reliable network running.
Please let me know if you are OK with it, if you object to it, or if you have a better idea.
Thanks,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
I think you're likely to find this a moving target.... As you mentioned, most ISPs do this in some fashion already. Conversely, you can also opt to buy your own cable or DSL modem, etc - but the onus is on you to deal with any "incompatibilities" identified by the carrier. For the most part, I would be perfectly fine with HamWAN doing the same function - provided it doesn't hamper my ability to do what "I want". Some examples of this would be port forwarding, traffic prioritization settings (from my internal stuff to the network, not network node to network node - that's "the carrier's" responsibility). Routing settings COULD be an issue, if I wanted to setup my own preferred alternate routes vs letting the backbone handle it (this is one of those "grey" areas). For the most part, I look for the following basic list of features: 1) My normal path through the network to other HamWAN hosts and the Internet is fast, short, and reliable 2) If anything in that path fails, my traffic re-routes without my knowing it and all continues to work well. 3) Any inbound defined services, such as port forwarding (for Echolink, etc) work under both #1 and #2. There is one situation I can think of that may run into problems with HamWAN managing remote endpoints.... that is the scenario where someone is developing RF-link based functionality that may be affected by an "auto-overwrite" by the network.... i.e. - someone is working on new antennas or testing traffic management possibilities. As an example - if I decide to replace my antenna with something "home brew" and want to modify the transmit or receive parameters for specific testing, there may be some conflicts here. Using other vendor radios or developing your own may be an issue as well. These can probably be handled using very few exceptions, and likely is not worth making major "policy" changes to accommodate, other than the potential for a few select devices to be excluded. Part of the excitement of developing this beast is simply not knowing everywhere it might take us. We may find more potential conflicts down the road that will have to be considered if/when they come up. Cheers, Rob Salsgiver - NR3O -----Original Message----- From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Bart Kus Sent: Thursday, February 28, 2013 4:17 PM To: Puget Sound Data Ring Subject: [HamWAN PSDR] POLL: How do you feel about HamWAN network having shared control of the microwave modem @ your location? Hello, Keeping the network and all client devices correctly configured is no easy feat. These are complicated devices with 100s of settings, which will need to change in coordinated ways over time. To ensure correct operation, it would make sense for the HamWAN network to push updates and change settings on end-user modems. Almost all ISPs run this way already. The difference is you can still login + control your device, but any setting changes you make which make the device non-compliant in ways HamWAN cares about would be automatically overridden with a config update from the network. If the network can't control and repair your device settings, you would lose authorization onto the network until the settings are fixed. I see this shared administration model as the only one that's feasible in keeping a reliable network running. Please let me know if you are OK with it, if you object to it, or if you have a better idea. Thanks, --Bart _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
My general rule of thumb for whether a feature is a good idea is this: What common, well-defined problem does it solve? Is this the only solution which solves that problem? What is the cost of this feature? Are we willing to bear that cost? On Thu, Feb 28, 2013 at 6:34 PM, Rob Salsgiver <rob@quailsoftltd.net> wrote:
I think you're likely to find this a moving target.... As you mentioned, most ISPs do this in some fashion already. Conversely, you can also opt to buy your own cable or DSL modem, etc - but the onus is on you to deal with any "incompatibilities" identified by the carrier.
For the most part, I would be perfectly fine with HamWAN doing the same function - provided it doesn't hamper my ability to do what "I want". Some examples of this would be port forwarding, traffic prioritization settings (from my internal stuff to the network, not network node to network node - that's "the carrier's" responsibility). Routing settings COULD be an issue, if I wanted to setup my own preferred alternate routes vs letting the backbone handle it (this is one of those "grey" areas).
For the most part, I look for the following basic list of features:
1) My normal path through the network to other HamWAN hosts and the Internet is fast, short, and reliable 2) If anything in that path fails, my traffic re-routes without my knowing it and all continues to work well. 3) Any inbound defined services, such as port forwarding (for Echolink, etc) work under both #1 and #2.
There is one situation I can think of that may run into problems with HamWAN managing remote endpoints.... that is the scenario where someone is developing RF-link based functionality that may be affected by an "auto-overwrite" by the network.... i.e. - someone is working on new antennas or testing traffic management possibilities. As an example - if I decide to replace my antenna with something "home brew" and want to modify the transmit or receive parameters for specific testing, there may be some conflicts here. Using other vendor radios or developing your own may be an issue as well. These can probably be handled using very few exceptions, and likely is not worth making major "policy" changes to accommodate, other than the potential for a few select devices to be excluded.
Part of the excitement of developing this beast is simply not knowing everywhere it might take us. We may find more potential conflicts down the road that will have to be considered if/when they come up.
Cheers, Rob Salsgiver - NR3O
-----Original Message----- From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Bart Kus Sent: Thursday, February 28, 2013 4:17 PM To: Puget Sound Data Ring Subject: [HamWAN PSDR] POLL: How do you feel about HamWAN network having shared control of the microwave modem @ your location?
Hello,
Keeping the network and all client devices correctly configured is no easy feat. These are complicated devices with 100s of settings, which will need to change in coordinated ways over time. To ensure correct operation, it would make sense for the HamWAN network to push updates and change settings on end-user modems. Almost all ISPs run this way already. The difference is you can still login + control your device, but any setting changes you make which make the device non-compliant in ways HamWAN cares about would be automatically overridden with a config update from the network. If the network can't control and repair your device settings, you would lose authorization onto the network until the settings are fixed.
I see this shared administration model as the only one that's feasible in keeping a reliable network running.
Please let me know if you are OK with it, if you object to it, or if you have a better idea.
Thanks,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
I totally agree with Rob's statement below. I fell asleep right after I read that ;-) Scott N7SS On Thu, Feb 28, 2013 at 6:34 PM, Rob Salsgiver <rob@quailsoftltd.net> wrote:
For the most part, I would be perfectly fine with HamWAN doing the same function - provided it doesn't hamper my ability to do what "I want".
Not everyone will have the ability or desire to manage or maintain the settings on their access device. Especially the more advanced settings. Therefore, I believe a properly authenticated message from the network that automatically alters a user's settings would be a good default configuration for them. However, the user is ultimately responsible for the operation of their station, so they should also have the ability to take responsibility for their own settings when desired. The user also has a responsibility to make sure their station doesn't cause harmful interference, so either way they should always honor a request from the network that asks them to shutdown their link. On Thu, Feb 28, 2013 at 8:21 PM, Scott Honaker <scotthon@pilchuckvet.com>wrote:
I totally agree with Rob's statement below. I fell asleep right after I read that ;-)
Scott N7SS
On Thu, Feb 28, 2013 at 6:34 PM, Rob Salsgiver <rob@quailsoftltd.net>wrote:
For the most part, I would be perfectly fine with HamWAN doing the same function - provided it doesn't hamper my ability to do what "I want".
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
On 2/28/2013 6:34 PM, Rob Salsgiver wrote:
I think you're likely to find this a moving target.... As you mentioned, most ISPs do this in some fashion already. Conversely, you can also opt to buy your own cable or DSL modem, etc - but the onus is on you to deal with any "incompatibilities" identified by the carrier. Yup, that's the right balance IMHO. For the most part, I would be perfectly fine with HamWAN doing the same function - provided it doesn't hamper my ability to do what "I want". That's my intention. Some examples of this would be port forwarding, This should be rarely needed, although it is possible to do. Remember, you have real-world IPs you can assign to your LAN and just use firewall rules to control access. No need to deal with translation and state-tracking. It's easier on the apps and the routers to take the no-NAT approach. traffic prioritization settings (from my internal stuff to the network, not network node to network node - that's "the carrier's" responsibility). This is another tricky open question. Yes, most fundamentally you do need control over your own QoS. However, HamWAN also provides you with multiple tiers of QoS depending on if you're operating emergency traffic, VoIP traffic, or regular traffic. How to implement this on the client side is an open engineering problem. It may just be VLAN-based, but that's kinda heavy. Routing settings COULD be an issue, if I wanted to setup my own preferred alternate routes vs letting the backbone handle it (this is one of those "grey" areas). Absolutely correct, and identified as an open issue in my not-so-clarifying clarification email. :) For the most part, I look for the following basic list of features:
1) My normal path through the network to other HamWAN hosts and the Internet is fast, short, and reliable Agreed. 2) If anything in that path fails, my traffic re-routes without my knowing it and all continues to work well. A valid scenario, although I'm sure some would say "you'll run SSL over HamWAN unknowingly and violate FCC rules" with this automation. I'm on the side of "Let the individual ham make the decision if they want to do automatic or manual default gateway failover". Can of worms. Another open engineering problem. 3) Any inbound defined services, such as port forwarding (for Echolink, etc) work under both #1 and #2. Yup. There is one situation I can think of that may run into problems with HamWAN managing remote endpoints.... that is the scenario where someone is developing RF-link based functionality that may be affected by an "auto-overwrite" by the network.... i.e. - someone is working on new antennas or testing traffic management possibilities. As an example - if I decide to replace my antenna with something "home brew" and want to modify the transmit or receive parameters for specific testing, there may be some conflicts here. Using other vendor radios or developing your own may be an issue as well. These can probably be handled using very few exceptions, and likely is not worth making major "policy" changes to accommodate, other than the potential for a few select devices to be excluded. Interesting, but given all the other open work, I'd like to postpone solving this. Part of the excitement of developing this beast is simply not knowing everywhere it might take us. We may find more potential conflicts down the road that will have to be considered if/when they come up.
Cheers, Rob Salsgiver - NR3O Agreed. And if this email is to teach us anything is that WE NEED MORE ENGINEERS WORKING THEIR ASSES OFF.
--Bart
-----Original Message----- From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Bart Kus Sent: Thursday, February 28, 2013 4:17 PM To: Puget Sound Data Ring Subject: [HamWAN PSDR] POLL: How do you feel about HamWAN network having shared control of the microwave modem @ your location?
Hello,
Keeping the network and all client devices correctly configured is no easy feat. These are complicated devices with 100s of settings, which will need to change in coordinated ways over time. To ensure correct operation, it would make sense for the HamWAN network to push updates and change settings on end-user modems. Almost all ISPs run this way already. The difference is you can still login + control your device, but any setting changes you make which make the device non-compliant in ways HamWAN cares about would be automatically overridden with a config update from the network. If the network can't control and repair your device settings, you would lose authorization onto the network until the settings are fixed.
I see this shared administration model as the only one that's feasible in keeping a reliable network running.
Please let me know if you are OK with it, if you object to it, or if you have a better idea.
Thanks,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
participants (5)
-
Bart Kus -
Benjamin Krueger -
Cory (NQ1E) -
Rob Salsgiver -
Scott Honaker