Ok, you're missing the point here so I'll spell it out: you cannot reliably deliver voice service over the public Internet in an enterprise environment. MPLS provides guaranteed RTT and QoS, end-to-end. I don't sell anything. I run a medium-large enteprise IP WAN and deliver voice service to several thousands sccp endpoints (along with mgcp/h.323 gateways, many thousands of VG analog ports, etc). You cannot reliably provide the same service over the public Internet with DMVPN.
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.
Will not solve the problems associated with running large VoIP deployments on the public Internet. Period. You have clearly never done this, you're just guessing because you used Skype once. You don't seem to understand how sensitive voice traffic is, so I'd suggest you do a little reading.
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.
Not on the Internet. Let me explain this in a concrete example so you understand why you can't run QoS on the Internet.
1. User A starts a VoIP call over your Internet connection. For some reason you QoS outbound VoIP traffic (even though it's "non-criticial" - your words)
2. User B starts to download a large file
3. As traffic leaves your router, towards the Internet, the VoIP traffic is given priority in the output queue.
4. Now, the traffic starts coming back. Your providers router now starts sending the traffic BACK to you. He has no outbound QoS policy to prioritize the RTP stream in his output queue. The large file traffic now completely stomps on the VoIP traffic, causing packet loss and delivery delays.
If QoS worked on the Internet, we'd all mark our traffic with the highest priority AND THEN QOS WOULDNT WORK ON THE INTERNET. Use your brain.
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.
We monitor and alert on our RTT in our NMS. I've had half a dozen LSP reengineered over the MPLS core and I've had loops reprovisioned to make sure they were meeting their SLA. Once again, you're speaking far beyond your level of experience.
Let's go over how completely wrong you are again:
1) Doesn't understand RTT SLA
2) Doesn't understand the need for inbound QoS
3) Thinks QoS works on the Internet
4) Thinks an interruption in voice service is acceptable
5) Thinks voice is a "non-critical" service.
Anyhow, be gone with you, Mr Jr Network admin for whatever unfortunate company.
I'm talking about RTT latency guarantees. My provider guarantees a CONUS 65ms RTT. I'm not talking about outage response time. I realize you have clearly never worked with leased circuits so this is totally lost on you. I'm sure you're learning a lot today.
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.
VoIP is delivered via RTP, a UDP protocol. A packet lost is an interruption in voice. You cannot redeliver it, because it would arrive out of order. The fact that you think "an occasional bit of jitter or packet loss will not ruin your conversation" shows me everything I need to know about your level of both experience and technical expertise.
You have CLEARLY never built or run a network carrying a signficant amount of voice services. You also don't understand the concept that you can only QoS outbound traffic, and that inbound traffic can't be prioritized towards your edge device resulting in - gasp! - jitter/loss. This is why QoS doesn't work on the Internet. And your bizarre theory that there isn't congestion or queueing delays on the Internet is just shockingly ignorant. I'm really done here, you are speaking from a place of ignorance -- you clearly have no experience in this arena and you have a LOT to learn.
And why does everyone assume that all traffic can be delivered over the Internet. A bunch of arm chair network engineers on slashdot, I swear to god. Let me know when you deliver voice to a few THOUSAND registered voice endpoints over DMVPN on the Internet and tell me how it goes for you.
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.
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.
I want to touch on this in particular, because I think you're confused. It's not about QoS on MY network, it's about all the intermediary devices respecting the QoS values that I set on traffic, and that traffic is delivered to CPE with the correct priority. What you do at the edge of your network, towards the Internet, has absolutely ZERO impact on how it's eventually delivered on the other end. MPLS provides guaranteed END-TO-END QoS. 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. NOTHING. That's why we call the Internet "Best Effort".
And if you think VoIP is non-critical, well, you're just completely fucking retarded. If you think someone picking up their phone and making a phone call is LESS important than how quickly a print job finishes, I can't help you. You're just clueless.
You don't seem to understand the concept of packet queues or jitter, so I'm going to assume that's why you seem to confuse the impact of both bandwidth and latency on the delivery of voice traffic. You cannot, I repeat, cannot, deliver voice to an enterprise over the Internet with any level of reliability. I'm not getting paid to explain this, so I'll leave it as an exercise to the reader to understand why. I think I've given you enough hints to do your own research. 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. But don't take my word for it, try to roll out a few thousand SIP endpoints and run it over the Internet and let me know how that goes for you.
You have no idea what you're talking about. Plain and simple. MPLS provides end to end SLA and packet prioritization. This allows me to classify voice/video over other traffic by setting DSCP values. That's how voice still works instead of being stomped on by other traffic. You cannot deliver voice over the Internet with any type of delivery guarantee. That's why private IP networks like frame relay and MPLS exist.
Oh you're one of those people who still has some stigma against Apple. Despite the fact that they are unequivocally better than any Windows laptop you can buy and numerous mainstream reviews have said that the Macbook with Windows is the best Windows laptop you can buy.
Yup, and the point still stands. The vast majority of professional gamers are using LCD panels now. What game do you think you play where it makes a difference? Are you a competitive counterstrike LAN player or something?
Yes and no. I'm not using wide-area L2. I'm using standard RFC2547 BGP/MPLS. And why does everyone assume you can't run IPSec over private point to multipoint WANs? It's just IP and BGP as far as I'm (the customer) is concerned. I peer with the PE via BGP and the routes come out on the other end.
Yeah, they changed that with iOS 5 I believe, I remember that. Turn it on and just get a picture of a USB cable and the iTunes icon. Ugh, it was the WORST. Now as opposed to the old theory that your Mac* (* device with iTunes installed, usually a PC) was your "digital hub" now that has shifted to "the cloud". You don't need to connect the device to anything to get it setup and start using it. Best thing they ever did.
Really? I've never tried it on my Pi. I did finally try XBMC on it the other day, and wow -- streaming 1080p over 100Mb fastethernet was flawless. I was shocked.
How most people use it doesn't matter. What matters is how Linus uses it. Which, technically, this isn't even really "written for". It's actually written for Android using Android APIs, the kernel doesn't really matter much. I think it's a stretch to say this is written "for Linux" in any sense, even strictly referring to the kernel.
You don't think that the Macbook Air keyboard is much better than the Surface keyboard? Have you ever compared them side-by-side? The larger, brighter screen wouldn't make it easier? The longer battery life?
You seem like a reasonable guy, so I'm curious -- what Surface? Is it a Surface Pro or WinRT? I assume you're just comfortable with Windows so you didn't want a Mac. I can totally appreciate that an iPad would be terrible for what you're doing. But why not a regular laptop? It seems to accomplish the same goal, but even better? Is it because you can also use a Surface like an iPad? I know some people like the Surface, I'm trying to figure out the use cases where it makes sense.
Slashdot Mirror
Ok, you're missing the point here so I'll spell it out: you cannot reliably deliver voice service over the public Internet in an enterprise environment. MPLS provides guaranteed RTT and QoS, end-to-end. I don't sell anything. I run a medium-large enteprise IP WAN and deliver voice service to several thousands sccp endpoints (along with mgcp/h.323 gateways, many thousands of VG analog ports, etc). You cannot reliably provide the same service over the public Internet with DMVPN.
1. Perform Audit
2. Mitigate where possible
3. Insure the rest
I've never seen anything that can't be delivered over the Internet
Now you have.
What are you using for your thousands of encrypted endpoints in your MPLS network?
GET VPN on ISR G2 at branches. Voice endpoints behind those.
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.
Will not solve the problems associated with running large VoIP deployments on the public Internet. Period. You have clearly never done this, you're just guessing because you used Skype once. You don't seem to understand how sensitive voice traffic is, so I'd suggest you do a little reading.
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.
Not on the Internet. Let me explain this in a concrete example so you understand why you can't run QoS on the Internet.
1. User A starts a VoIP call over your Internet connection. For some reason you QoS outbound VoIP traffic (even though it's "non-criticial" - your words)
2. User B starts to download a large file
3. As traffic leaves your router, towards the Internet, the VoIP traffic is given priority in the output queue.
4. Now, the traffic starts coming back. Your providers router now starts sending the traffic BACK to you. He has no outbound QoS policy to prioritize the RTP stream in his output queue. The large file traffic now completely stomps on the VoIP traffic, causing packet loss and delivery delays.
If QoS worked on the Internet, we'd all mark our traffic with the highest priority AND THEN QOS WOULDNT WORK ON THE INTERNET. Use your brain.
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.
We monitor and alert on our RTT in our NMS. I've had half a dozen LSP reengineered over the MPLS core and I've had loops reprovisioned to make sure they were meeting their SLA. Once again, you're speaking far beyond your level of experience.
Let's go over how completely wrong you are again:
1) Doesn't understand RTT SLA
2) Doesn't understand the need for inbound QoS
3) Thinks QoS works on the Internet
4) Thinks an interruption in voice service is acceptable
5) Thinks voice is a "non-critical" service.
Anyhow, be gone with you, Mr Jr Network admin for whatever unfortunate company.
You are, a fucking dipshit. Bye.
That's a SLA contract issue, NOT a technical one.
I'm talking about RTT latency guarantees. My provider guarantees a CONUS 65ms RTT. I'm not talking about outage response time. I realize you have clearly never worked with leased circuits so this is totally lost on you. I'm sure you're learning a lot today.
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.
VoIP is delivered via RTP, a UDP protocol. A packet lost is an interruption in voice. You cannot redeliver it, because it would arrive out of order. The fact that you think "an occasional bit of jitter or packet loss will not ruin your conversation" shows me everything I need to know about your level of both experience and technical expertise.
You have CLEARLY never built or run a network carrying a signficant amount of voice services. You also don't understand the concept that you can only QoS outbound traffic, and that inbound traffic can't be prioritized towards your edge device resulting in - gasp! - jitter/loss. This is why QoS doesn't work on the Internet. And your bizarre theory that there isn't congestion or queueing delays on the Internet is just shockingly ignorant. I'm really done here, you are speaking from a place of ignorance -- you clearly have no experience in this arena and you have a LOT to learn.
And why does everyone assume that all traffic can be delivered over the Internet. A bunch of arm chair network engineers on slashdot, I swear to god. Let me know when you deliver voice to a few THOUSAND registered voice endpoints over DMVPN on the Internet and tell me how it goes for you.
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.
I want to touch on this in particular, because I think you're confused. It's not about QoS on MY network, it's about all the intermediary devices respecting the QoS values that I set on traffic, and that traffic is delivered to CPE with the correct priority. What you do at the edge of your network, towards the Internet, has absolutely ZERO impact on how it's eventually delivered on the other end. MPLS provides guaranteed END-TO-END QoS. 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. NOTHING. That's why we call the Internet "Best Effort".
And if you think VoIP is non-critical, well, you're just completely fucking retarded. If you think someone picking up their phone and making a phone call is LESS important than how quickly a print job finishes, I can't help you. You're just clueless.
You don't seem to understand the concept of packet queues or jitter, so I'm going to assume that's why you seem to confuse the impact of both bandwidth and latency on the delivery of voice traffic. You cannot, I repeat, cannot, deliver voice to an enterprise over the Internet with any level of reliability. I'm not getting paid to explain this, so I'll leave it as an exercise to the reader to understand why. I think I've given you enough hints to do your own research. 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. But don't take my word for it, try to roll out a few thousand SIP endpoints and run it over the Internet and let me know how that goes for you.
You have no idea what you're talking about. Plain and simple. MPLS provides end to end SLA and packet prioritization. This allows me to classify voice/video over other traffic by setting DSCP values. That's how voice still works instead of being stomped on by other traffic. You cannot deliver voice over the Internet with any type of delivery guarantee. That's why private IP networks like frame relay and MPLS exist.
Oh you're one of those people who still has some stigma against Apple. Despite the fact that they are unequivocally better than any Windows laptop you can buy and numerous mainstream reviews have said that the Macbook with Windows is the best Windows laptop you can buy.
Any other arbitrary guidelines you'd like to throw in?
Here's the Chromebook Pixel. It's 3:2 at 2560x1700. I don't know if you want wider or taller since you didn't specify.
Yup, and the point still stands. The vast majority of professional gamers are using LCD panels now. What game do you think you play where it makes a difference? Are you a competitive counterstrike LAN player or something?
Yes and no. I'm not using wide-area L2. I'm using standard RFC2547 BGP/MPLS. And why does everyone assume you can't run IPSec over private point to multipoint WANs? It's just IP and BGP as far as I'm (the customer) is concerned. I peer with the PE via BGP and the routes come out on the other end.
But to your second point, absolutely agree.
First of all, you assume I'm not using IPSec. And I get a little thing called QoS which let's me deliver voice and video.
Which is why MPLS exists and we build private WANs. The REAL answer here is because Pointy-Haired-Boss wants to be able to login from home,
Why? They have no idea what the password is for. If they already have a rainbow table, they already "know" your password. I don't see the issue?
Yeah, they changed that with iOS 5 I believe, I remember that. Turn it on and just get a picture of a USB cable and the iTunes icon. Ugh, it was the WORST. Now as opposed to the old theory that your Mac* (* device with iTunes installed, usually a PC) was your "digital hub" now that has shifted to "the cloud". You don't need to connect the device to anything to get it setup and start using it. Best thing they ever did.
Really? I've never tried it on my Pi. I did finally try XBMC on it the other day, and wow -- streaming 1080p over 100Mb fastethernet was flawless. I was shocked.
You'd have to sit closer than 17" to discern an individual pixel. That's probably an unnecessarily high PPI. No one sits that close to a monitor.
Sure you can. Unless you mean you just can't afford it?
A 1080p 4" display becomes "retina" at 6 inches. A 4K display is retina at 3 inches. How close to the eye are the displays on the Oculus Rift?
Souce: http://isthisretina.com/
Here's the calculator you're looking for: http://isthisretina.com/
I'd be willing to bet modern 120hz TN panels are fast enough that you cannot discern a difference.
How most people use it doesn't matter. What matters is how Linus uses it. Which, technically, this isn't even really "written for". It's actually written for Android using Android APIs, the kernel doesn't really matter much. I think it's a stretch to say this is written "for Linux" in any sense, even strictly referring to the kernel.
You don't think that the Macbook Air keyboard is much better than the Surface keyboard? Have you ever compared them side-by-side? The larger, brighter screen wouldn't make it easier? The longer battery life?
You seem like a reasonable guy, so I'm curious -- what Surface? Is it a Surface Pro or WinRT? I assume you're just comfortable with Windows so you didn't want a Mac. I can totally appreciate that an iPad would be terrible for what you're doing. But why not a regular laptop? It seems to accomplish the same goal, but even better? Is it because you can also use a Surface like an iPad? I know some people like the Surface, I'm trying to figure out the use cases where it makes sense.