Most MPLS networks are implemented using pure IP/BGP implementations, not L2 VPNs
Your statement doesn't even make sense. MPLS *is* a "L2 VPN" technology. What do you think the "L" in MPLS stands for? If it wasn't acting like a VLAN, and separating each customer's traffic, you would see traffic from the MPLS network of the company down the street (you don't have dedicated physical links). Instead the label switching, like VLAN tagging, is keeping it separate at the layer-2 level. BGP and IP are layer-3 protocols, so there's really no such thing as "pure IP/BGP". You've still got MPLS on layer 2, doing tagging, just like VLANs do.
Look, talk to a voice engineer, talk to someone (other than me) who's deployed large networks and voice installations.
You've been talking to one (me) for quite a while, and he (I) keeps telling you that everything coming out of your mouth is nonsensical bull crap.
Not only do I not believe you've ever "deployed" a "large network", I don't believe you've ever managed a small network. The nonsense and patently obvious ignorance of basic networking concepts completely undermines your false assertions of your own imaginary (lack of) skills.
You seem to think there's some coherency between data streams from different hosts passing through a router, they have no idea about one another.
No he never said anything of the sort. The "coherency" comes from the buffer/queue of the "router" that is getting both streams.
The router can choose to drop packets from the large file download until the speed falls, while NOT dropping any packets from the RTP stream. That's real QoS / fair queuing... The kind of thing any entry level network engineer knows about, but yet you still believe is mythical or magical. Anybody who has ever set-up even a single router almost certainly knows about fair queuing, so apparently, you have not.
No matter how many times you loudly repeat your denials, your ignorance / incompetence of networking will not change these facts.
You shouldn't need "clean water" for "flushing". Toilets are an IDEAL application for "grey water". Just slightly filter the waste water from showering, hand-washing, etc., and send it into your toilet. The water (and sewer flow) from flushing your toilet could well be completely free, as you would have had just as much use and output (of grey water) with no toilet.
Tell them how the FED creating $80+ billion per month doesnt make the value of their savings disappear.
Considering that inflation is still staying well below the usual 3%, I'd have to say it doesn't have much if any impact.
Artificially keeping interest rates ridiculously low is having more of an effect on most people, including myself, as the 0.1% interest I'm earning on my cash doesn't keep up with ANY amount of inflation.
I've always been fascinated by people who keep dangerous pets or work with them.
Nearly ALL pets are dangerous. Birds, cats dogs, ALL can maim or kill you if they are sufficiently motivated.
But you only have to piss off a grizzly bear one time
The same is true of a medium to large dog. Bears are at least smart enough (like dogs) to know better. There are locations in Canada where people feed polar bears quite well, in exchange for them not eating their dogs, and they behave quite well. Watching polar bears and dogs playfully wrestling with one-another is a sight to see.
Big cats are far more instinctive. Siegfried and Roy deserve lots of credit for going so long before a maiming, but they're also the exceptions. Buddhist monks seem to be the only ones with the proper temperament to keep large cats. Contrast this with dogs, where the majority of people will do fine and not get themselves killed.
So let's try again. I said: A packet lost is an interruption in voice. The link says: Packet loss causes interrupts.
No, you're just misquoting them. They're saying *significant* packet loss will be a problem. You said *any* packet loss will be audible. Their statement is true, if simplistic. Your statement is completely incorrect, and no amount of back-peddling will change it.
tell me all about the ACKs used during the transmission of UDP RTP stream
You're suggesting that someone will "download a large file" using RTP? (those are precisely your words)
everyone would just set THEIR traffic to the highest priority.
You've still utterly failed to explain why this same thing supposedly can't happen on MPLS.
you cannot control the output queue on your ISPs router
Indirectly, you can. Throttling, queuing, prioritizing ACKs, RED, etc. If you handle queuing properly, you'll prevent your ISP's router queue from filling, and therefore eliminate delays and bursts. Any entry-level network engineer should know that extremely well.
Take your router, tag your VoIP traffic and then download a Linux ISO via bittorrent. Watch what happens.
The fact that you don't know how to do it doesn't make it impossible, or even difficult for a beginner to do. Go look-up a few Cisco papers on fair queuing before further demonstrating your ignorance. This is stuff you'll need to know before you can hope to get a job in the field, so it'll be time well-spent.
Some frothing-at-the-mouth cave dweller mad because someone somewhere might be better at what he does than he is. Yes, good bye is probably the best choice for you, you are in over your head at your job, and here.
I don't think so. With all the factually incorrect comments jon3k has made in a tangential thread, I don't believe he has any VoIP knowledge, but worse, I don't see that he has more than entry-level knowledge of networking at all (incorrect statements on queuing and whatnot).
My guess is he is either some new college graduate who has a lot of time to read about this stuff but has never played with any of it. Or some Junior Network Admin who does mindless grunt work on someone else's large corporate network, but doesn't actually engineer or really understand any of it. Then again, it could be some combination of the two.
You don't seem to understand how sensitive voice traffic is, so I'd suggest you do a little reading.
You said: "A packet lost is an interruption in voice." Your link says: "Some degree of packet loss won't be noticeable"
ie. You're not a VoIP engineer.
The large file traffic now completely stomps on the VoIP traffic, causing packet loss and delivery delays.
Except it doesn't, because none of the internet protocols are one-way broadcasts. Controlling the ACKs sent out directly controls the speed of incoming traffic. NO network admins responsible for a network larger than 10 people would make a stupid ignorant mistakes like this. Weighted fair queuing is CCNA-level network bare-bones network admin basics. A network won't even be USABLE for two people at the same time if proper queuing isn't enabled.
ie. You're not even a network engineer.
If QoS worked on the Internet, we'd all mark our traffic with the highest priority AND THEN QOS WOULDNT WORK ON THE INTERNET.
This isn't even a coherent thought. Replace "internet" with "MPLS" and it would still work just fine.
Tagging isn't QoS. You don't NEED QoS "on the internet" as the backbone is fast. You need QoS on the bottleneck, which is always your uplink, and your network admin (which you are not) controls the queues and hence QoS on those.
2) Doesn't understand the need for inbound QoS
You've made it clear you don't even understand what QoS or queuing IS or DOES. Having my knowledge insulted by you is practically a compliment at this point.
Your comments in this thread are one of the best examples I've even seen of the old adage:
"It is better to keep your mouth closed and let people think you are a fool, than to open it and remove all doubt."
Factually inaccurate statements make me doubt your story about deploying VoIP on a large scale. UDP makes no difference, and your incorrect assertion that VoIP has ZERO forward error correction is something I wouldn't even expect from an entry level CCNA.
And for the record, you most certainly can throttle incoming connections, it's just not as finely controllable and beneficial as outgoing QoS, which is more common. But I made it clear the first time around I was talking about controlling both ends of the connection.
For that matter, I think I was extremely clear that I was talking about latency guarantees by the rest of my statement you didn't quote... They are empty promises of service you'd be getting anyways, and only worth the price of the penalties your ISP has agreed to pay. It's not at all unusual for companies of offer ridiculously impossible SLAs, knowing it'll bring in more business, and paying the penalties is cheaper than actually maintaining that level of service.
Anyhow, be gone with you, Mr Jr Network admin for whatever unfortunate company.
I don't know if you're a troll or ignorant, but I always follow this rule of thumb: never attribute to malice what you can attribute to ignorance, so I'll assume the latter.
Actually, the problem is YOUR ignorance, here, so you're still failing to understand what I'm explaining to you.
The fact that you can write a route-map and slap a DSCP value on a packet as it leaves your router out onto the Internet does absolutely NOTHING to guarantee delivery
I never said anything about DSCP. "Tagging" a packet is the isn't QoS, it's just telling the devices further down the line how you want them to do the QoS. By just tagging it and pushing it out, you're simply leaving it to your ISP's routers to do the actual QoS, and let them put your VoIP packets higher in their buffers/queues (rather than prioritizing them higher in YOUR buffers/queues and throttling other traffic).
The congestion is never on the backbone. The bottleneck is always the slow ISP link to the endpoints (eg. your OC-3 or whatever). That's why managing the queuing of your packets in and out of your network is sufficient, and will give you very good performance even with low-latency applications.
And if you think VoIP is non-critical, well, you're just completely fucking retarded
VoIP has been designed to handle a reasonable amount of packet loss. An occasional bit of jitter or packet loss will not ruin your conversation.
MPLS provides guaranteed END-TO-END QoS.
That's a SLA contract issue, NOT a technical one. When your ISPs routers are overloaded and your MPLS has trouble, you'll get a tiny amount of money back from them, while you won't get the same payout because of similar trouble with your internet connection. Nothing about MPLS guarantees that a router will never be oversubscribed, it just says your ISP will try, just slightly harder, to deliver your packet first, in the event of congestion.
I have spent a decade designing, implementing and maintaining large scale enterprise WANs and very large voice deployments (many thousands of endpoints, every conceivable form of gateways and trunks - mgcp, h.323, sip, pri, fxs, etc etc etc). I assure you, you have NO IDEA how to implement a functioning enterprise voice system.
Fun. But I happen to have been in the game well over a decade, so your CV doesn't impress me. The fact that you don't seem to understand how QoS actually works suggests a superficial knowledge of the subject, and an unfortunate deference to expensive "magic" services provided by others.
If you're in an environment where the folks at the top are happy to waste obscene amounts of money on unnecessary services, you may manage well enough. But you really make yourself less valuable that way, and may make yourself look stupid if you ever move up to a position where your colleagues aren't as ignorant, and look at you funny when you insist that what they've been doing for years, "...won't work without buying the magic tiger-repelling rock!"
You cannot deliver voice over the Internet with any type of delivery guarantee
No, but you don't NEED a "guarantee". A great many people use VoIP successfully over the internet every day. There are extremely few companies where the quality of the calls are ultra-critical. A 911 emergency response center would be one, but even for high profile business activities, a rare packet delay or drop will barely be noticeable, and won't have any effects on business operations.
That's how voice still works instead of being stomped on by other traffic.
Having QoS on the routers, firewalls, or whatever endpoint at BOTH ends, will also allow you to prioritize voice traffic, and throttle all others.
Long gone are the days of congested backbones. The congestion is in the "last mile", and you can control that with QoS queue prioritize and throttling at both of your endpoints.
MPLS is a terribly expensive choice if all you need it for is allowing you to avoid doing proper QoS on your own network.
There are some (few) good reasons to do MPLS, like multi-site failover using the same IP space. But QoS for non-critical workloads like VoIP certainly isn't one of the worthwhile ones.
Yes, because if you are, then the high cost of MPLS is quite pointless for you. The end-points being on an MPLS network are harder to reach by the public, but you could pretty well accomplish the same thing with a good firewall dropping communications to/from your IPSec endpoint from every IP other than the single intended source/destination IP address. You could harden it to an extreme degree with a bridging/transparent firewall.
And I get a little thing called QoS which let's me deliver voice and video.
Voice and video travel over the internet quite well.
If I'm a purchaser, especially a bulk-purchaser, I'm expected to do some comparison. That means going through log-ins on all your stupid sites, instead of being able to automate it in some sane way.
It doesn't work that way. If you're "a purchaser" you're only comparing prices from the handful of approved sellers that your company has already worked-out a contract terms with.
Only once in a great while, if you're ambitious, will you decide a product is massively over-priced, and start looking around for the cheapest, and if it's a SUBSTANTIAL price different, may recommend negotiating terms with that company as a new supplier.
It's quite different from consumer purchases, where the cheapest price, every time, is all you care about, no matter who you have to buy it from.
Damn, I never heard of it before, it never showed up in my searches for parts.
Geeks.com was a reseller on Amazon.com, and you could find their products via pricewatch.com or froogle.
I bought from them a few times, but they never really rose above the noise because their selection was small and patchy, and their inventory wasn't very deep, so they'd alternate, being out-of-stock on an item for weeks, then it being available again.
All that said, I don't see why they'd shut-down their online store. If they're not making enough money, raise your prices! Maybe reduce your selection from 500 different webcams down to just a couple as well. If you still need all the same infrastructure to service your retail store and other online store, how much manpower can maintaining geeks.com really need? Perhaps a handful of employees? And you aren't making enough profits to pay them?
This may seem out of left field, but I was recently pondering the efficacy of lasers for submarine communications.
Only the very lowest radio frequencies penetrate a short distance below the surface of the ocean. The broadcasting equipment for those are enormous multi-megawatt monsters which can only transmit a minuscule amount of data, amounting to maybe a sentence per hour.
But with certain wavelengths of lasers, you can get penetration up to ~115 meters.
Even if the range is less, I'm sure submarine fleets would appreciate the option of laser-based two-way communications with satellites, without needing to surface.
Other than strategically placed buoys, is there even any other option for modernizing submarine communications past our current circa 1960s methods?
Because exchanging information with other systems is necessary.
Because people off-site want or need to monitor the status.
Because routinely plug a USB flash drive into a net-connected computer, and then into the air-gapped network (to update software or exchange other info/data) isn't actually much more secure.
Because there are varying degrees of "critical".
Because if it's really a "critical" system, you don't want to wait for tech support to arrive on-site to get problems fixed.
Because "the internet" itself happens to be a "critical" system.
Because the old days of connecting systems to the PSTN (eg. dial-in modems) wasn't actually any more secure than connecting them to the internet.
Because having an air-gapped network provides a false sense of security, that can fall apart in a big way.
This just one more example of why critical systems should never be connected to the internet.
Platitudes are oh-so-easy to spout off, no matter how ignorant you are of the issue, but don't offer any insight or solutions to the root cause of the problems.
Rape cases always hinge on the credibility of the accuser, so they can go from rock solid to nothing in no time. And the timing is purely coincidental, a lot of *STUFF* happen in ~4 months.
They were so confident that the press is a fucking joke that they barely even TRIED to hide it. And they were right too.
Well, if it was so poorly concealed, you should be able to dig up incriminating evidence, no problem. Any time now... Let me know how that works out for you.
When the head of the IMF starts challenging the primacy of the U.S. dollar for example, you don't assassinate him. Way too messy and risky. Instead, you arrange for something a little more subtle, but just as effective.
911 Truth! Gubmint satellites are reading your brain waves!
See, that's the thing about "laws" - they're written by the legislature and confirmed by the executive branch. Unless and until the judicial branch finds them to be technically inadequate or violating the constitution, they ARE the law.
No, if they're obviously in conflict with the Constitution, they're NOT the law, and you can be prosecuted, (eg. for denying someone their civil rights, even if you try hiding behind an unconstitutional law that said it was legal...
It was extended from 17 to 20 years for "international conformance",
No, it was SHORTENED from 17 years after GRANT date, down to 20 years after FILING date. Grant date was routinely much more than 3 years after filing, so it was significantly shortened, and made much more predictable when patents expired.
If you don't believe me, just try and stop paying those MP3 patent license fees... The mostly-complete MPEG-1 draft standard was initially published in September 1990, just shy of 23 years ago, yet the patents are still in-force for a while to come.
South Korea has a history of international broadcasting. If citizens of NK could tune-in the signal, the south would be only too happy to keep an analog tower transmitting near the DMZ. It's probably only because the north has locked down receivers so much that the south isn't even trying anymore.
And besides that, you're talking about a TV tuner connected to a CPU... There's very much a possibility of custom software taking the digital signal from the analog tuner, and decoding it. There's some difficulty with many common analog tuner chips cutting off part of the signal, but SK could invent their own digital signal that could be decoded on such a device, if they could tune-in a clear channel, and there was a big enough audience in the north. But that's a bit more of a stretch, and as I said, radio is a very good medium for that sort of thing.
Slashdot Mirror
Your statement doesn't even make sense. MPLS *is* a "L2 VPN" technology. What do you think the "L" in MPLS stands for? If it wasn't acting like a VLAN, and separating each customer's traffic, you would see traffic from the MPLS network of the company down the street (you don't have dedicated physical links). Instead the label switching, like VLAN tagging, is keeping it separate at the layer-2 level. BGP and IP are layer-3 protocols, so there's really no such thing as "pure IP/BGP". You've still got MPLS on layer 2, doing tagging, just like VLANs do.
You've been talking to one (me) for quite a while, and he (I) keeps telling you that everything coming out of your mouth is nonsensical bull crap.
Not only do I not believe you've ever "deployed" a "large network", I don't believe you've ever managed a small network. The nonsense and patently obvious ignorance of basic networking concepts completely undermines your false assertions of your own imaginary (lack of) skills.
No he never said anything of the sort. The "coherency" comes from the buffer/queue of the "router" that is getting both streams.
The router can choose to drop packets from the large file download until the speed falls, while NOT dropping any packets from the RTP stream. That's real QoS / fair queuing... The kind of thing any entry level network engineer knows about, but yet you still believe is mythical or magical. Anybody who has ever set-up even a single router almost certainly knows about fair queuing, so apparently, you have not.
No matter how many times you loudly repeat your denials, your ignorance / incompetence of networking will not change these facts.
You shouldn't need "clean water" for "flushing". Toilets are an IDEAL application for "grey water". Just slightly filter the waste water from showering, hand-washing, etc., and send it into your toilet. The water (and sewer flow) from flushing your toilet could well be completely free, as you would have had just as much use and output (of grey water) with no toilet.
Considering that inflation is still staying well below the usual 3%, I'd have to say it doesn't have much if any impact.
Artificially keeping interest rates ridiculously low is having more of an effect on most people, including myself, as the 0.1% interest I'm earning on my cash doesn't keep up with ANY amount of inflation.
Nearly ALL pets are dangerous. Birds, cats dogs, ALL can maim or kill you if they are sufficiently motivated.
The same is true of a medium to large dog. Bears are at least smart enough (like dogs) to know better. There are locations in Canada where people feed polar bears quite well, in exchange for them not eating their dogs, and they behave quite well. Watching polar bears and dogs playfully wrestling with one-another is a sight to see.
Big cats are far more instinctive. Siegfried and Roy deserve lots of credit for going so long before a maiming, but they're also the exceptions. Buddhist monks seem to be the only ones with the proper temperament to keep large cats. Contrast this with dogs, where the majority of people will do fine and not get themselves killed.
No, you're just misquoting them. They're saying *significant* packet loss will be a problem. You said *any* packet loss will be audible. Their statement is true, if simplistic. Your statement is completely incorrect, and no amount of back-peddling will change it.
You're suggesting that someone will "download a large file" using RTP? (those are precisely your words)
You've still utterly failed to explain why this same thing supposedly can't happen on MPLS.
Indirectly, you can. Throttling, queuing, prioritizing ACKs, RED, etc. If you handle queuing properly, you'll prevent your ISP's router queue from filling, and therefore eliminate delays and bursts. Any entry-level network engineer should know that extremely well.
The fact that you don't know how to do it doesn't make it impossible, or even difficult for a beginner to do. Go look-up a few Cisco papers on fair queuing before further demonstrating your ignorance. This is stuff you'll need to know before you can hope to get a job in the field, so it'll be time well-spent.
I don't think so. With all the factually incorrect comments jon3k has made in a tangential thread, I don't believe he has any VoIP knowledge, but worse, I don't see that he has more than entry-level knowledge of networking at all (incorrect statements on queuing and whatnot).
http://slashdot.org/comments.pl?sid=4046997&cid=44472765
My guess is he is either some new college graduate who has a lot of time to read about this stuff but has never played with any of it. Or some Junior Network Admin who does mindless grunt work on someone else's large corporate network, but doesn't actually engineer or really understand any of it. Then again, it could be some combination of the two.
You said: "A packet lost is an interruption in voice."
Your link says: "Some degree of packet loss won't be noticeable"
ie. You're not a VoIP engineer.
Except it doesn't, because none of the internet protocols are one-way broadcasts. Controlling the ACKs sent out directly controls the speed of incoming traffic. NO network admins responsible for a network larger than 10 people would make a stupid ignorant mistakes like this. Weighted fair queuing is CCNA-level network bare-bones network admin basics. A network won't even be USABLE for two people at the same time if proper queuing isn't enabled.
ie. You're not even a network engineer.
This isn't even a coherent thought. Replace "internet" with "MPLS" and it would still work just fine.
Tagging isn't QoS. You don't NEED QoS "on the internet" as the backbone is fast. You need QoS on the bottleneck, which is always your uplink, and your network admin (which you are not) controls the queues and hence QoS on those.
You've made it clear you don't even understand what QoS or queuing IS or DOES. Having my knowledge insulted by you is practically a compliment at this point.
Your comments in this thread are one of the best examples I've even seen of the old adage:
"It is better to keep your mouth closed and let people think you are a fool, than to open it and remove all doubt."
ignorance + arrogance = idiocy
Factually inaccurate statements make me doubt your story about deploying VoIP on a large scale. UDP makes no difference, and your incorrect assertion that VoIP has ZERO forward error correction is something I wouldn't even expect from an entry level CCNA.
And for the record, you most certainly can throttle incoming connections, it's just not as finely controllable and beneficial as outgoing QoS, which is more common. But I made it clear the first time around I was talking about controlling both ends of the connection.
For that matter, I think I was extremely clear that I was talking about latency guarantees by the rest of my statement you didn't quote... They are empty promises of service you'd be getting anyways, and only worth the price of the penalties your ISP has agreed to pay. It's not at all unusual for companies of offer ridiculously impossible SLAs, knowing it'll bring in more business, and paying the penalties is cheaper than actually maintaining that level of service.
Anyhow, be gone with you, Mr Jr Network admin for whatever unfortunate company.
Actually, the problem is YOUR ignorance, here, so you're still failing to understand what I'm explaining to you.
I never said anything about DSCP. "Tagging" a packet is the isn't QoS, it's just telling the devices further down the line how you want them to do the QoS. By just tagging it and pushing it out, you're simply leaving it to your ISP's routers to do the actual QoS, and let them put your VoIP packets higher in their buffers/queues (rather than prioritizing them higher in YOUR buffers/queues and throttling other traffic).
The congestion is never on the backbone. The bottleneck is always the slow ISP link to the endpoints (eg. your OC-3 or whatever). That's why managing the queuing of your packets in and out of your network is sufficient, and will give you very good performance even with low-latency applications.
VoIP has been designed to handle a reasonable amount of packet loss. An occasional bit of jitter or packet loss will not ruin your conversation.
That's a SLA contract issue, NOT a technical one. When your ISPs routers are overloaded and your MPLS has trouble, you'll get a tiny amount of money back from them, while you won't get the same payout because of similar trouble with your internet connection. Nothing about MPLS guarantees that a router will never be oversubscribed, it just says your ISP will try, just slightly harder, to deliver your packet first, in the event of congestion.
Fun. But I happen to have been in the game well over a decade, so your CV doesn't impress me. The fact that you don't seem to understand how QoS actually works suggests a superficial knowledge of the subject, and an unfortunate deference to expensive "magic" services provided by others.
If you're in an environment where the folks at the top are happy to waste obscene amounts of money on unnecessary services, you may manage well enough. But you really make yourself less valuable that way, and may make yourself look stupid if you ever move up to a position where your colleagues aren't as ignorant, and look at you funny when you insist that what they've been doing for years, "...won't work without buying the magic tiger-repelling rock!"
No, but you don't NEED a "guarantee". A great many people use VoIP successfully over the internet every day. There are extremely few companies where the quality of the calls are ultra-critical. A 911 emergency response center would be one, but even for high profile business activities, a rare packet delay or drop will barely be noticeable, and won't have any effects on business operations.
Having QoS on the routers, firewalls, or whatever endpoint at BOTH ends, will also allow you to prioritize voice traffic, and throttle all others.
Long gone are the days of congested backbones. The congestion is in the "last mile", and you can control that with QoS queue prioritize and throttling at both of your endpoints.
MPLS is a terribly expensive choice if all you need it for is allowing you to avoid doing proper QoS on your own network.
There are some (few) good reasons to do MPLS, like multi-site failover using the same IP space. But QoS for non-critical workloads like VoIP certainly isn't one of the worthwhile ones.
Yes, because if you are, then the high cost of MPLS is quite pointless for you. The end-points being on an MPLS network are harder to reach by the public, but you could pretty well accomplish the same thing with a good firewall dropping communications to/from your IPSec endpoint from every IP other than the single intended source/destination IP address. You could harden it to an extreme degree with a bridging/transparent firewall.
Voice and video travel over the internet quite well.
It doesn't work that way. If you're "a purchaser" you're only comparing prices from the handful of approved sellers that your company has already worked-out a contract terms with.
Only once in a great while, if you're ambitious, will you decide a product is massively over-priced, and start looking around for the cheapest, and if it's a SUBSTANTIAL price different, may recommend negotiating terms with that company as a new supplier.
It's quite different from consumer purchases, where the cheapest price, every time, is all you care about, no matter who you have to buy it from.
Geeks.com was a reseller on Amazon.com, and you could find their products via pricewatch.com or froogle.
I bought from them a few times, but they never really rose above the noise because their selection was small and patchy, and their inventory wasn't very deep, so they'd alternate, being out-of-stock on an item for weeks, then it being available again.
All that said, I don't see why they'd shut-down their online store. If they're not making enough money, raise your prices! Maybe reduce your selection from 500 different webcams down to just a couple as well. If you still need all the same infrastructure to service your retail store and other online store, how much manpower can maintaining geeks.com really need? Perhaps a handful of employees? And you aren't making enough profits to pay them?
This may seem out of left field, but I was recently pondering the efficacy of lasers for submarine communications.
Only the very lowest radio frequencies penetrate a short distance below the surface of the ocean. The broadcasting equipment for those are enormous multi-megawatt monsters which can only transmit a minuscule amount of data, amounting to maybe a sentence per hour.
But with certain wavelengths of lasers, you can get penetration up to ~115 meters.
http://www.laseroptronix.se/techinfo/Waterabsorption.pdf
Even if the range is less, I'm sure submarine fleets would appreciate the option of laser-based two-way communications with satellites, without needing to surface.
Other than strategically placed buoys, is there even any other option for modernizing submarine communications past our current circa 1960s methods?
READ BETTER
There aren't enough superlatives in the language to emphasize this point enough.
A paragraph from the very damn comment you're replying to:
"Because the old days of connecting systems to the PSTN (eg. dial-in modems) wasn't actually any more secure than connecting them to the internet."
Has nobody here seen the movie "War Games"? What's with all the completely mindless anti-Internet Ludditeism?
Sorry, but your MPLS WAN is far LESS SECURE than a proper IPSec tunnel over the internet, while being vastly more expensive.
RIGHT! Having a dial-in modem on the PTSN was OH-SO-MUCH MORE SECURE!
Has absolutely NOBODY here ever seen the movie "War Games"?
Because exchanging information with other systems is necessary.
Because people off-site want or need to monitor the status.
Because routinely plug a USB flash drive into a net-connected computer, and then into the air-gapped network (to update software or exchange other info/data) isn't actually much more secure.
Because there are varying degrees of "critical".
Because if it's really a "critical" system, you don't want to wait for tech support to arrive on-site to get problems fixed.
Because "the internet" itself happens to be a "critical" system.
Because the old days of connecting systems to the PSTN (eg. dial-in modems) wasn't actually any more secure than connecting them to the internet.
Because having an air-gapped network provides a false sense of security, that can fall apart in a big way.
Platitudes are oh-so-easy to spout off, no matter how ignorant you are of the issue, but don't offer any insight or solutions to the root cause of the problems.
Rape cases always hinge on the credibility of the accuser, so they can go from rock solid to nothing in no time. And the timing is purely coincidental, a lot of *STUFF* happen in ~4 months.
Well, if it was so poorly concealed, you should be able to dig up incriminating evidence, no problem. Any time now... Let me know how that works out for you.
911 Truth! Gubmint satellites are reading your brain waves!
No, if they're obviously in conflict with the Constitution, they're NOT the law, and you can be prosecuted, (eg. for denying someone their civil rights, even if you try hiding behind an unconstitutional law that said it was legal...
No, it was SHORTENED from 17 years after GRANT date, down to 20 years after FILING date. Grant date was routinely much more than 3 years after filing, so it was significantly shortened, and made much more predictable when patents expired.
If you don't believe me, just try and stop paying those MP3 patent license fees... The mostly-complete MPEG-1 draft standard was initially published in September 1990, just shy of 23 years ago, yet the patents are still in-force for a while to come.
South Korea has a history of international broadcasting. If citizens of NK could tune-in the signal, the south would be only too happy to keep an analog tower transmitting near the DMZ. It's probably only because the north has locked down receivers so much that the south isn't even trying anymore.
And besides that, you're talking about a TV tuner connected to a CPU... There's very much a possibility of custom software taking the digital signal from the analog tuner, and decoding it. There's some difficulty with many common analog tuner chips cutting off part of the signal, but SK could invent their own digital signal that could be decoded on such a device, if they could tune-in a clear channel, and there was a big enough audience in the north. But that's a bit more of a stretch, and as I said, radio is a very good medium for that sort of thing.