I think that might be a red herring. The new Macbook Air has a 14 hour battery life. I'd like to see what percentage of that power is spent on the drive. I think even if we made SSDs twice as power efficient, I don't think it would have a marked improvement in overall battery life. I think it's all about CPU and display power consumption.
I'm not sure a Chrysler Seabring is much better than a riding lawn mower. But I agree with your post wholeheartedly, other than that. To Microsoft's credit, they saw "the web" coming a mile away, they just couldn't turn their massive ship fast enough. Microsoft isn't going to "die" anymore than IBM "died", the question just becomes what does the Microsoft of, say, 2023 look like?
I think the web already delivered on that far more than virtualization will. The reality is that the vast majority of applications aren't written as OS specific compiled binaries anymore.
SDN was really more designed for large leaf-spline datacenters, honestly. A lot of people are questioning it's value with regards to small datacenters or large IP WANs.
People aren't getting any more "IT literate". Computers are just getting easier to use (eg: iPad). As someone who works in IT, I truly welcome easier to use systems, and the pipe dream of "smarter users" (really meaning: more technically competent, they're all generally bright people). We have a massive shortage of skilled IT works, at least here in the US.
The consolidating of IT resources in "the cloud" will hopefully allow us to centralize the maintenance of thousands of disparate, duplicate-function IT systems (eg: the millions of scattered fileservers, all administered independently, many of them poorly) into the hands of a few highly skilled professionals, so that's encouraging (and admittedly, a little scary).
I love the guys who come on slashdot to read bleeding edge tech news then complain that it's not a product in the marketplace yet. Cracks me up. You cold post this comment in basically everything on slashdot. You might as well go read engadget.
I'll give this one more shot. Most MPLS networks are implemented using pure IP/BGP implementations, not L2 VPNs. The _VAST_ majority. Putting VPNs on MPLS is someting we came up with later. Usually how it works is, the CE peers with the PE via [e]BGP. Then from the PE to the LSR and switched across the MPLS core. I say switched and not routed because it's using label switching. Notice how none of this is Layer 2? There's a/30 between me and the PE, and I peer via BGP on a circuit (typically) running PPP (although I've had quite a few circuits delivered via metro-e as well). This is far and away the most common implementation. Again, don't believe me, call up any MPLS provider (I can give you some suggestions if you'd like) and ask them.
1) Calling SANs "security experts" is incredibly myopic. There stated goal is security but they work with lots of ACTUAL experts, in lots of fields.
2) Good news: all of it is still relevent, but feel free to point out anything I quoted that isn't. Turns out protocols don't change a whole lot.
3) Yes it does. (eg "In IP telephony packet loss is unacceptable. ")
Here's the bottom line: I've seen people use broadband for voice backup during leased circuit outages -- it's horrible. I always use analog POTS and SRST. Voice on the Internet can be done, it works some of the time and when it fails you just kind of shrug and go "oh well, nothing we can do". Look, talk to a voice engineer, talk to someone (other than me) who's deployed large networks and voice installations. But don't call the guy with running Asterisk using some random SIP trunking service, I'm talking about real legitimate installations delivering consistent, real service.
TCP windowing, using ACKs, is designed to transfer as much data as possible. Client A has no concept that Client B is sending voice traffic. Client A will cause disruptions to voice traffic when downloading large files. This isn't a theory. 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.
Look, don't believe me - try it yourself. Setup an RTP stream between two endpoints over the Internet, enable whatever features you want (eg - QoS), and then download a Linux ISO via bittorrent.
I'm only referring to the Surface Pro. Read what I posted again, carefully. Microsoft WISHES those laptops were the competitors. In reality, most consumers compare the Surface Pro to an iPad. Reading is FUN-damental.
None of those are direct competitors. That's what Microsoft wishes were the direct competitors, but really it's the iPad. It also only has a 4 hour battery life and a miserable (by comparison) keyboard.
Here, don't believe me, believe SANs. Seriously, you can yell and argue but you clearly have a lot to learn and that's a decent overview to get you started.
In IP telephony packet loss is unacceptable. The performance of an IP call will suffer greatly if packet loss occurs. The quality of the conversation will lag if packet loss reaches more than 5%
From experience, 5% packet loss would make for a completely unacceptable level of quality. At least relative on the level of service I provide.
Delays in voice traffic create gaps in the transmission that may be heard by the receiver, resulting in unhappy customers. QOS technology features concrete priority service to voice traffic to establish predictable delivery. Usually small in size, transmission of voice packets range from 80 to 256 bytes. Unless QOS techniques are used such voice packets can be delayed between larger data packets. QOS techniques used are packet fragmentation and interleaving. One of the crucial technical issues with QOS is that in order to be effective it must be supported end-to end. For VoIP to be of functional quality the network should essentially have a bare minimum data rate and bounded delay variation.
If QoS mechanisms are supported on only portions of the network there are no guarantees that the traffic will get the handling end-to-end that is necessary to achieve success.
You said: "A packet lost is an interruption in voice."
Your link says: "Some degree of packet loss won't be noticeable"
You forgot the whole quote:
Packet loss causes interrupts. Some degree of packet loss won't be noticeable, but lots of packet loss will make sound lousy.
So let's try again. I said: A packet lost is an interruption in voice.
The link says: Packet loss causes interrupts.
Sure, you might get lucky with sub 1% packet loss during breaks in speech.
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.
Yes, tell me all about the ACKs used during the transmission of UDP RTP stream (spoiler: there is no such thing as a UDP ACK, it's a TCP function). Your ignorance continues to astound. Let's pretend for a second that UDP actually sent ACKs and you could rate limit the inbound VoIP traffic. Now you've introduced delay, causing jitter. Out of order packets are of course dropped, because that would produce garbled voice. Put simply: "How are you today" becomes "How you today are".
Great plan.
This isn't even a coherent thought. Replace "internet" with "MPLS" and it would still work just fine.
Just because you don't understand it doesn't mean it doesn't make sense. QoS tagging isn't respected on the Internet, because everyone would just set THEIR traffic to the highest priority. Once all traffic is set to the highest priority, there's no way to differentiate and all traffic ends up in the same output queue.
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.
This is just ignorant drivel. This braindead concept you have that the only point of saturation is OUTBOUND traffic leaving your edge device is just ignorance. Ever wonder why most consumer broadband connections are asymmetric? Because there's more traffic received than sent.
You don't understand that you cannot control the output queue on your ISPs router is just lost on you. Look, if you don't believe me, try it. Take your router, tag your VoIP traffic and then download a Linux ISO via bittorrent. Watch what happens.
You've made it clear you don't even understand what QoS or queuing IS or DOES.
Yes, clearly. Look it's painfully obvious you have no idea what you're talking about with regards to delivering voice, and even basic networking concepts are completely lost on you. It's becoming painfully awkward to even respond to you, I feel like I'm scolding a child.
You are so catastrophically wrong I don't even know where to begin, but I'll give it a shot. Quite simply, MPLS wasn't created specifically to transport L2 traffic. It was a replacement for frame relay. That's basically it. Wide area Layer 2 was just a feature. You seem to think that MPLS was designed to carry Ethernet. It wasn't. That's why we have EoMPLS. It's not native to the protocol, we encapsulate ethernet and transports it over an MPLS core.
One of us is advocating deploying VoIP on the public Internet. The other is advocating deploying VoIP over a secure MPLS network. One of us knows what the fuck he's talking about. The other one doesn't. I'll let you guess which is which.
I mourn for your users.
Well, considering my network provides end-to-end delivery guarantees and you use the best-effort Internet, I think mine will be far better off. Oh right, you don't actually build networks. You're a "Security Expert".
No you fucking idiot, I'm saying you cannot deploy VoIP on the public Internet. Fuck you're dim. Of course you can literally SEND rtp traffic over the Internet, it's just UDP datagrams. What I'm saying is IN PRACTICE YOU CANNOT DO IT AND HAVE A FUNCTIONING VOICE PLATFORM.
OH, a "security expert". Gotcha. You really aren't qualified to have a discussion on the delivery of voice service to a large, geographically distributed IP WAN with me. Twas nice talking to you.
Slashdot Mirror
I think that might be a red herring. The new Macbook Air has a 14 hour battery life. I'd like to see what percentage of that power is spent on the drive. I think even if we made SSDs twice as power efficient, I don't think it would have a marked improvement in overall battery life. I think it's all about CPU and display power consumption.
This is great for writes but I don't see how it helps for reads? You're just hoping the 8GB you need is in the cache. Smells like bullshit to me.
Your iPad mini is also slower and has a far lower resolution display.
I'm not sure a Chrysler Seabring is much better than a riding lawn mower. But I agree with your post wholeheartedly, other than that. To Microsoft's credit, they saw "the web" coming a mile away, they just couldn't turn their massive ship fast enough. Microsoft isn't going to "die" anymore than IBM "died", the question just becomes what does the Microsoft of, say, 2023 look like?
I think the web already delivered on that far more than virtualization will. The reality is that the vast majority of applications aren't written as OS specific compiled binaries anymore.
SDN was really more designed for large leaf-spline datacenters, honestly. A lot of people are questioning it's value with regards to small datacenters or large IP WANs.
Plot twist: these guys are talking about each other
People aren't getting any more "IT literate". Computers are just getting easier to use (eg: iPad). As someone who works in IT, I truly welcome easier to use systems, and the pipe dream of "smarter users" (really meaning: more technically competent, they're all generally bright people). We have a massive shortage of skilled IT works, at least here in the US.
The consolidating of IT resources in "the cloud" will hopefully allow us to centralize the maintenance of thousands of disparate, duplicate-function IT systems (eg: the millions of scattered fileservers, all administered independently, many of them poorly) into the hands of a few highly skilled professionals, so that's encouraging (and admittedly, a little scary).
I love the guys who come on slashdot to read bleeding edge tech news then complain that it's not a product in the marketplace yet. Cracks me up. You cold post this comment in basically everything on slashdot. You might as well go read engadget.
Good argument.
/30 between me and the PE, and I peer via BGP on a circuit (typically) running PPP (although I've had quite a few circuits delivered via metro-e as well). This is far and away the most common implementation. Again, don't believe me, call up any MPLS provider (I can give you some suggestions if you'd like) and ask them.
I'll give this one more shot. Most MPLS networks are implemented using pure IP/BGP implementations, not L2 VPNs. The _VAST_ majority. Putting VPNs on MPLS is someting we came up with later. Usually how it works is, the CE peers with the PE via [e]BGP. Then from the PE to the LSR and switched across the MPLS core. I say switched and not routed because it's using label switching. Notice how none of this is Layer 2? There's a
1) Calling SANs "security experts" is incredibly myopic. There stated goal is security but they work with lots of ACTUAL experts, in lots of fields.
2) Good news: all of it is still relevent, but feel free to point out anything I quoted that isn't. Turns out protocols don't change a whole lot.
3) Yes it does. (eg "In IP telephony packet loss is unacceptable. ")
Here's the bottom line: I've seen people use broadband for voice backup during leased circuit outages -- it's horrible. I always use analog POTS and SRST. Voice on the Internet can be done, it works some of the time and when it fails you just kind of shrug and go "oh well, nothing we can do". Look, talk to a voice engineer, talk to someone (other than me) who's deployed large networks and voice installations. But don't call the guy with running Asterisk using some random SIP trunking service, I'm talking about real legitimate installations delivering consistent, real service.
TCP windowing, using ACKs, is designed to transfer as much data as possible. Client A has no concept that Client B is sending voice traffic. Client A will cause disruptions to voice traffic when downloading large files. This isn't a theory. 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.
Look, don't believe me - try it yourself. Setup an RTP stream between two endpoints over the Internet, enable whatever features you want (eg - QoS), and then download a Linux ISO via bittorrent.
Read what I said again. Carefully.
I'm only referring to the Surface Pro. Read what I posted again, carefully. Microsoft WISHES those laptops were the competitors. In reality, most consumers compare the Surface Pro to an iPad. Reading is FUN-damental.
None of those are direct competitors. That's what Microsoft wishes were the direct competitors, but really it's the iPad. It also only has a 4 hour battery life and a miserable (by comparison) keyboard.
I was kind of with him until the "You go, Al Queda!" part. As much as you might disagree with US policy, two wrongs don't make a right.
In IP telephony packet loss is unacceptable. The performance of an IP call will suffer greatly if packet loss occurs. The quality of the conversation will lag if packet loss reaches more than 5%
From experience, 5% packet loss would make for a completely unacceptable level of quality. At least relative on the level of service I provide.
Delays in voice traffic create gaps in the transmission that may be heard by the receiver, resulting in unhappy customers. QOS technology features concrete priority service to voice traffic to establish predictable delivery. Usually small in size, transmission of voice packets range from 80 to 256 bytes. Unless QOS techniques are used such voice packets can be delayed between larger data packets. QOS techniques used are packet fragmentation and interleaving. One of the crucial technical issues with QOS is that in order to be effective it must be supported end-to end. For VoIP to be of functional quality the network should essentially have a bare minimum data rate and bounded delay variation.
If QoS mechanisms are supported on only portions of the network there are no guarantees that the traffic will get the handling end-to-end that is necessary to achieve success.
You said: "A packet lost is an interruption in voice." Your link says: "Some degree of packet loss won't be noticeable"
You forgot the whole quote:
Packet loss causes interrupts. Some degree of packet loss won't be noticeable, but lots of packet loss will make sound lousy.
So let's try again. I said: A packet lost is an interruption in voice.
The link says: Packet loss causes interrupts.
Sure, you might get lucky with sub 1% packet loss during breaks in speech.
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.
Yes, tell me all about the ACKs used during the transmission of UDP RTP stream (spoiler: there is no such thing as a UDP ACK, it's a TCP function). Your ignorance continues to astound. Let's pretend for a second that UDP actually sent ACKs and you could rate limit the inbound VoIP traffic. Now you've introduced delay, causing jitter. Out of order packets are of course dropped, because that would produce garbled voice. Put simply: "How are you today" becomes "How you today are".
Great plan.
This isn't even a coherent thought. Replace "internet" with "MPLS" and it would still work just fine.
Just because you don't understand it doesn't mean it doesn't make sense. QoS tagging isn't respected on the Internet, because everyone would just set THEIR traffic to the highest priority. Once all traffic is set to the highest priority, there's no way to differentiate and all traffic ends up in the same output queue.
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.
This is just ignorant drivel. This braindead concept you have that the only point of saturation is OUTBOUND traffic leaving your edge device is just ignorance. Ever wonder why most consumer broadband connections are asymmetric? Because there's more traffic received than sent.
You don't understand that you cannot control the output queue on your ISPs router is just lost on you. Look, if you don't believe me, try it. Take your router, tag your VoIP traffic and then download a Linux ISO via bittorrent. Watch what happens.
You've made it clear you don't even understand what QoS or queuing IS or DOES.
Yes, clearly. Look it's painfully obvious you have no idea what you're talking about with regards to delivering voice, and even basic networking concepts are completely lost on you. It's becoming painfully awkward to even respond to you, I feel like I'm scolding a child.
Go ahead, prove me wrong.
Oh shoot, almost forgot.
You are so catastrophically wrong I don't even know where to begin, but I'll give it a shot. Quite simply, MPLS wasn't created specifically to transport L2 traffic. It was a replacement for frame relay. That's basically it. Wide area Layer 2 was just a feature. You seem to think that MPLS was designed to carry Ethernet. It wasn't. That's why we have EoMPLS. It's not native to the protocol, we encapsulate ethernet and transports it over an MPLS core.
I mourn for your users.
Well, considering my network provides end-to-end delivery guarantees and you use the best-effort Internet, I think mine will be far better off. Oh right, you don't actually build networks. You're a "Security Expert".
No you fucking idiot, I'm saying you cannot deploy VoIP on the public Internet. Fuck you're dim. Of course you can literally SEND rtp traffic over the Internet, it's just UDP datagrams. What I'm saying is IN PRACTICE YOU CANNOT DO IT AND HAVE A FUNCTIONING VOICE PLATFORM.
MPLS exists to economically sell VLANs over shared networks.
Read this carefully: You. Have. No. Idea. What. You. Are. Talking. About.
Bye.
Haha, suuuuure. I can tell by the fact that you don't know the difference between MPLS and VPLS that you're quite the expert on WAN design.
OH, a "security expert". Gotcha. You really aren't qualified to have a discussion on the delivery of voice service to a large, geographically distributed IP WAN with me. Twas nice talking to you.