Tech Forum

jasondivy wrote:

Well don't tell them that.

I'm not going to lie, even by omission. If that's the route we go, then they deserve to know.

What lie? Saying that it's the only option that is endorsed and supported by the church implicitly indicates that there may be other options but it doesn't emphasize it. Saying "It's technically possible, but..." makes it sound like it should work but somebody is incompetent or otherwise isn't doing what they could do. It has negative connotations towards the church's technical team and/or decision makers. I don't think that's called for and would keep my explanation to the main point.

I don't think so. The VPN is only used for some data. The whole internet doesn't go through there.

Then why is it so much faster to run a speed test when you bypass the 881? And why does the speed test tell me that my signal is originating in the wrong city? (It gives me the correct city when I bypass.) I conclude that every speed test I've run has gone across the VPN. I know you can't get internet when that light is off (but that's not conclusive).

And the webcast solution is based on Azure. So it's not inside the VPN.

Irrelevant. Don't get hung up on the idea that QOS is entirely for intranet service. QOS is regularly used for webcasts, video conferencing, VOIP, and other mission critical high-bandwidth or low-latency applications -- even if the other end is across the Internet.

The other problem is that the church needs a configuration that works with all ISPs.

And why wouldn't it? I've outlined several reasons why it would. Your turn.

And you've already pointed out that UDP isn't very manageable.

How many people are using UDP to surf the web? We could simply block UDP. If someone felt like being fancy, we could have a switch on tm.lds.org to turn UDP on and off. I included it for completeness, not because it was an actual problem. A deliberate DDOS is always a problem, unless the church wants to have dedicated lines. In other words, even if you turn wireless off you still have this problem.

Because the Church does not choose to expend tithing funds on industrial strength bandwidth, what we have becomes a precious resource that we reserve solely for the broadcast if we wish to get the signal through to our outlying units.

That's exactly what I'm talking about, but without the unnecessary inconvenience of shutting out stake members. I'm not suggesting we run enterprise grade fiber to every building. I'm suggesting we make sane use of the DSL and cable connections that we have.

Saying "It's technically possible, but..." makes it sound like it should work but somebody is incompetent or otherwise isn't doing what they could do. It has negative connotations towards the church's technical team and/or decision makers.

Are you really going make me spell it out for you? No, I don't think church leaders are being incompetent. I do think someone has really dropped the ball on this. (someone on the technical staff)

Do you think we are automatically perfect because we belong to the church? Does being part of the technical staff of the church make you immune to mistakes? Of course not. The Lord even chewed out Joseph from time to time. ALL of us err. You and me included. When I err, I get called on it, especially when other people are relying on me.

They didn't give us the ability to manage the 881. Fine. I get it. I wouldn't either. But that means that it needs to be properly set up to begin with. I don't think it is.

To this point, nobody has enunciated a single good reason why they haven't dealt with this. Maybe a reason exists. At this point, I conclude it is likely that there is no good reason. Either someone overlooked it, or someone doesn't want to be bothered.

jasondivy wrote:To this point, nobody has enunciated a single good reason why they haven't dealt with this. Maybe a reason exists. At this point, I conclude it is likely that there is no good reason. Either someone overlooked it, or someone doesn't want to be bothered.

And I conclude there is a good reason, but we haven't been told about it. I base that on past issues that seemed to have no good reason, only to learn there is one. Sometimes it's just priorities or amount of effort required didn't justify the benefit. Sometimes there really is a technical issue. When you do get a chance to talk to the folks at CHQ, you find they're not a clueless as it might seem.

russellhltn wrote:TM (Technology Manager) has the ability to shut off all the wireless in the building.

The first time I tested this feature of TM, I found that it shut off the 881W wireless and the 1041n WAPs, but it did not shut off the legacy Cisco Aeronet 1200 in the stake center. I had to manually turn off that WAP.

drepouille wrote:

russellhltn wrote:TM (Technology Manager) has the ability to shut off all the wireless in the building.

The first time I tested this feature of TM, I found that it shut off the 881W wireless and the 1041n WAPs, but it did not shut off the legacy Cisco Aeronet 1200 in the stake center. I had to manually turn off that WAP.

Ah, good point. It's also not likely to run off any legacy APs that were installed back when it was all installed on the stake's dime.

jasondivy wrote:I only found the recommendation to turn wifi off after starting this post. (I was actively hunting for the answer.) Most STS won't find it at all. I wonder how many stake conferences are going to have bizarre, intermittent problems before they discover that little nugget...

The checklist for managing a webcast event https://www.lds.org/help/support/manage-webcast-event includes "Disable Meetinghouse Internet Wireless Access to preserve Internet bandwidth at each location."

This message is displayed prominently on the TM home page: "Wireless access may now be disabled/enabled through Technology Manager. For meetinghouses the Stake Technology Specialist or Stake/District/Ward/Branch presidencies may do so under the direction of the meetinghouse Stake/District President. The disable feature prevents devices from using LDSAccess."

Here is a case where QOS doesn't mean a hill-o-beans when it comes to a webcast. I was an STS in a stake with 9 meetinghouses, 7 of which had no better than 1.54Mbps down speeds, the stake center we did our webcasts from also was in this speed range, which meant that the upload was barely 300K.

This solution is designed to be successful from a site with MAX 300Kbps upload speeds and still be successful. I don't disagree that if I had a 50Mbps pipe that some kind of QOS could be put in place to allow the wireless and those at the meetinghouse usage while the webcast is going on. But, it isn't applicable in all cases, and, frankly, could become a worse situation, for those not very technical, to understand at what point it would be ok to tell members they can use their devices, and when they can't. The Wireless ON/Wireless OFF works no matter what. I think the KISS principle applies.

I work in and environment where QOS is used heavily internally between our data centers, and externally on circuits between our clients and our data centers, I've seen it blow up, I've seen it react differently in versions of code on the routers, I've seen a need to tweak ongoing as bandwidth is increased or decreased or new solutions come into play. Using a personal vpn will bypass it, too many complications IMHO.

jasondivy wrote:Everyone is going to be expecting to have Internet access for their phones, not the least of which will be the high council. Take that away from them, and we'll hear no end of grumbling and "why not"s I'd rather not have to tell them that it's technically possible, but out of our hands.

Prior to our recent multi-stake conference, I sent out multiple e-mails to all leaders, asking them to tell everyone attending the conference that the wireless in the stake center would be disabled. They were asked to bring scriptures, either on paper or on a cell data plan. As the attendees arrived, we could see a few with puzzled looks on their faces as they tried to use their devices, but they survived.

We had a multi-stake broadcast recently and unfortunately the satellite feed went down, so the backup was brought into play at very short notice. A PC using an Internet feed. To make sure we didn't have buffering problems, I shut down the wifi access to the building, 15 minutes before the start of the broadcast. I made a quick announcement to the audience to that effect. No one complained, or even commented about the lack of wifi access. Even the late comers, who hadn't heard the announcement!!

So, I am a STS and have implemented my own version of QOS. During Stake Conference broadcasts to our three other buildings and shut-ins I go through several steps to create an equivalent of QOS for our broadcast. I remotely shutdown the wireless from my broadcast sites and receiving sites. I really love this ability. I then manually go in and pull the ethernet cables from every port on the 881 except my connections for the VidiU device and the system controlling the VidiU device. I had to do this because I have had the occasion where some clerk or other individual has decided to access the internet through a clerks hardwired access DURING conference no less. I had notified the Stake Presidency and High Council of such action. The Stake Presidency have given me permission to take whatever measures necessary to provide the best possible streaming experience within the confines of explicit or implicit church policy. (Explicit and implicit as per my interpretation so do not start a thread on these definitions please.)