TechWiseTV

Voice Quality you can Quantify

New podcast posted today...but let me set it up first.  

It is quite fitting that Jimmy Ray posted yesterday on the value of QoS vs. Bandwidth and role of DiffServ.  These are the technical ‘wrap around the axle’ type things we collectively get excited about learning and working with.  However, we also must be careful to not lose focus on the end goal...what really matters?  When it comes to IP Telephony and successful user adoption, all that matters is what the end user says matters: Perception is Reality. 

This is simple right? All we need to do now is make sure that we develop and implement technology solutions that our end users will agree has been done right.  We are end users ourselves are we not...so there is a measure we can use.  Ahhh....measure.  We need an accurate, objective measure that we can use to establish a benchmark...in this way we can then improve and measure our improvement, set goals and so forth.   The MOS or Mean Opinion Score has long been the preferred method for objectively measuring the quality of a voice call or link.  But is it enough? One company is finding success in showing what gets left out of that measurement. Namely, the fact that you can have a great MOS score and still get complaints from users... remember:  Perception is Reality.

We found a very fascinating company named Psytechnics at the VoiceCon show and we both got a chance to interview their CTO, Dr. Mike Hollier. 

Please check out our latest podcast.

Hold Music

I opened a ticket with Cisco last week to have my hold music removed...  I feel like hold music for individual phones needs to be retired.  It was a cutting edge at one point in time... it even took some time to become standard on IP phones for various reasons.   But think about how easy it is, as an individual knowledge worker, to forget that you even have that as a service....its like my wife telling me I snore...I do not!  I never hear it...I slept great last night.

Well, everyone else can hear my hold music... which does not just happen when you push the hold button but also anytime you use the transfer or conference features. These are great if you are talking to one person but how many of us are spending our time on conference calls?  Quite a few I bet.  We all HATE the imbecile who puts a con call on hold and forces everyone to listen to their usually crummy music. Well, I always wanted to blame that idiot and then when I got my new IP phone at home as an official remote worker...I became that idiot. 

I was lurking on a con call... did not have much to offer myself so I did not think twice when I saw that my wife was trying to call me.  I answered her call which put my con call on hold...chatted a bit and before I could return to the con call I was getting nasty text messages...  One nice thing about conference bridges these days is the ability to identify visually what line has activity on it... the conference leader had simply asked everyone to be quiet for a moment and he was quickly able to call me out as the protocol offender and muted my line....which meant also that I was not only humiliated (kind of a strong word but it does fit) but my line was now muted by the system if I decided to un-lurk and try to participate. An electronic banishment in our age of collaborative communications. 

I do want to call for a ban on hold music.... it is annoying for everyone.  If you have it on your phone, get it removed. It can be done on Cisco phones...I know it can, I seen me do it. (obscure Ron White reference)

Serve up the DiffServ

I was out on a call this morning and the network admin was mad that the users thought the VOIP system they installed sucked. Truth is it did. If MOS scores could be in the negative, theirs would have been in the Kelvins. They thought that with high speed 10GB switches they did not need QoS in their network. On paper that would make sense, however, when packets start hitting the switch, all bets are off until they start existing. 

Networks are like kids; they start small and grow big then don’t listen to what you have to say. To keep up with the demand vendors have been building faster switches with deeper buffers every single year. This is an example of

Moore's Law at its finest. But is that enough? Of course any Account Manager will say YES! Buy more Cisco, problem solved. But a realistic network engineer needs to consider the role Quality of Service (QoS) will play in their network. Most folks understand how 802.1p works. DiffServ seems to be the big unknown in the world of QoS.

 The real term is Differentiated Services but the alpha geek crowd just says DiffServ. If you say DiffServ folks know you are down with the set yo. If you say Differentiated Services folks will point you to the server admin crowd… DiffServ is concerned with classifying packets as they enter the local network. This classification then applies to a flow of traffic where a flow is defined by 5 elements:

- Source IP address

- Destination IP

- Source port

- Destination port

- Transport protocol.

A flow that has been classified or marked can then be acted upon by other QoS mechanisms. Multiple flows can therefore be dealt with in a multitude of ways depending on the requirements of each flow. Voice this way and data that way, etc… DiffServ uses a Code Point (the cool way to say this is DSCP) to determine the per hop behavior of the flow. Kinda like how you can determine who does what on Star Trek by what color shirt they wear. Blue is Medical, Gold is Command and Red is the one that always gets killed off. Back to DSCP, there are 64 total DSCP values. They range from 0-63. Remember that a high DSCP value does is not equal to a high QoS queue. However, understand that in the Assured Forwarded (more to come…) there are three drop probabilities. The DSCP determines the Per-Hop Behavior (PHB) of a flow. In a nutshell, packets are first classified according to their current DSCP. Then they are separated into queues where one queue may be routed via a marking mechanism and another queue may be examined more closely. After further examination additional packets may be sent for marking or be sent direct to the shaping/dropping mechanisms where all packets end up before leaving the interface. Just like on Star Trek NG, everyone always ends up in 10Forward to pound down some alien Newcastle Pale Ales after a mission.

 How cool is that! Differentiated Services provides a simple and quick (all be it) coarse method of classifying services of various applications. Of course there is more to then that, so let’s get geeky with it man! You don’t get off that easy…  There are currently two standard per hop behaviors (PHBs) defined that effectively represent two service levels. Although others are possible, but these are the most common and most widely used.

 · Expedited Forwarding (EF): This is like riding in First Class on a long trip. This is the best possible. EF has a single codepoint. EF minimizes delay and jitter and provides the highest level of aggregate quality of service and guaranteed bandwidth. Any traffic that exceeds the traffic profile (which is defined by local QoS policy) is discarded.

· Assured Forwarding (AF): This is like riding in coach with extra leg room for business class. AF has four classes and three drop precedence within each class (so a total of twelve codepoints). Excess AF traffic is not delivered with as high probability as the traffic “within profile,” which means it may be demoted but not necessarily dropped.

 As you are mapping your DSCP’s ensure that you understand which traffic flows to map to EF and which flows to map to AF. Although DiffServ is not backward compatible with ToS, DiffServ can be used to actually replace Type of Service if it is mapped correctly. I have included a chart if you ever need to do this:

 DSCP  Precedence  Purpose

0  0 Best effort

8  1 Class 1

16  2  Class 2

24  3   Class 3

32  4  Class 4

40  5  Express forwarding

48  6  Control

56  7  Control

 DiffServ assumes the existence of a service level agreement (SLA) between networks that share a border. The SLA establishes the policy criteria, and defines the traffic profile. It is expected that traffic will be policed and smoothed at egress points according to the SLA, and any traffic “out of profile” (i.e. above the upper-bounds of bandwidth usage stated in the SLA) at an ingress point have no guarantees (or may incur extra costs, according to the SLA). The policy criteria used can include time of day, source and destination addresses, transport, and/or port numbers (i.e. application Ids). Basically, any context or traffic content (including headers or data) can be used to apply policy.

The best part of DiffServ is its simplicity to prioritize traffic and its flexibility and power. Cisco switches fully support DiffServ. When DiffServ is the primary QoS parameter, specific application types can be used to identify and classify traffic, it will be possible to establish well-defined aggregate flows that may be directed to fixed bandwidth pipes. As a result, you could share resources efficiently and still provide guaranteed service. That is the true power and flexibility of QoS.

 

Jimmy Ray

 

 

 

Mailbox RFiD

I grew on a gentleman’s farm in the hills Tennessee. We had a party line until I was in high school, drank from a spring and we had a RFD mailbox address. It was a very simple and great way to grow up. I can not help but reminisce about life on the farm when I hear the term RFID. It reminds me of our old mailbox, sitting crooked in an older milk can with the hand lettered words RFD 122. That simple metal box was the connection to the world outside of Iron City, Tennessee. As Alphonse Karr said: “The more things change, the more they stay the same…”

Radio Frequency Identification is basically made up of three parts (not counting the access points) tags, readers, software to correlate the tags. Breaking that down a little more, there are two types of tags; passive and active. Simply speaking, if the tag has a battery, it is active. Your wireless solution can really enhance a RFID solution just like a great road can enhance your driving experience. It works like this; the reader “lights up” the tag with a radio wave. The tag responds with data it has prestored in it, the reader forwards this to via radio waves to the wireless network, then to the RFID correlation software, that updates the database and your done.

We have been using RFID since 1995. The real change has been in the frequencies used. Retail stores have been using high frequency (13.56MHz) tags on things like clothes, stereo equipment, etc. Those are the devices that set off the alarms when you try to boost a limited edition Englebert Humperdink full sequence jacket from the store. Darn it… When RFID is positioned today, it takes on the incredibly overused term; convergence. As an engineer myself, we are always trying to converge something over to IP; phones, power, storage, video gaming and now RFID. The technical term for this is job security. All kidding aside, the real benefit of bringing RFID solutions into the IP network is much lower acquisition, maintenance and security cost. Plus we get to use a cool new term; Ultra High Frequency RFID tags and that gives us much more geek-cred to our peeps. 

If you read any of the literature about RFID from goober analyst, it would seem that RFID can do everything from inventory control to making sure your kids get to school on time. I have been involved in many RFID implementations (mainly at hospitals) and the question to ask yourself before moving towards an RFID discovery process is; “How can my business processes improve if I can track assets better” I am not a big fan of RFID being implemented exclusively for loss prevention, unless your losses are staggering. Loss prevention is a positive side effect of RFID, but normally not a primary business justifier.

I have seen RFID provide nearly instant value and payback in the follow types of deployments: 

Distribution Centers. Sending and receiving can be automated by RFID tags by reducing the amount of folks needed to manually check-in incoming items as well as the time/energy spent proving items have (or have not) been delivered. RFID can also ensure that outgoing shipments are accurate, complete and loaded on the right truck. Then of course loss prevention benefit kicks in since RFID tracks the movement of assets within the Distribution Center.

Supply chain. A quick way to lose a customer is too not have an item in stock. The real problem is the not the distance of the distribution center to the store, but from the stores loading dock to the front end. Many items can be placed behind other boxes or inside bigger boxes resulting in an invisible inventory. RFID can give store operators the visibility to prevent an out of stock issue. Plus RFID can make sure the store is stocked to meet store sales/promos like day after Thanksgiving sales. Nothing makes me more angry then when my favorite stores are sold out of Billy Bass.

Kid tracking.  Medical facilities more then any other business have perfected and really honed the use of RFID. In many new born nurseries, the new borns are tagged with a RFID bracelet. By using RFID location based services to track the new born, hospital staff knows at all times where a child is. If the child is moved to an unauthorized zone, cameras will automatically train to the location and in many instances doors will lock to trap the child in that contained area. As a result, new born thefts have dropped in some areas to zero and there is no worry that the wrong new born is gave to the wrong mother since the mother and new borns RFID bracelet numbers match. 

Cool stuff right? Sky is the limit when it comes to RFID. Those examples are very basic installs. Keep in mind that anytime we have to deal with radio waves, implementation can be tricky. Radio waves have varying characteristics at different frequencies. Wireless technology is cheap as far as equipment cost go, it is the design/troubleshooting tools that cost the cash. For a successful RFID implementation, I would recommend the following steps as a guideline for your business.

Business Stuff:

- As the business lead, are you and your team clear on want RFID can and can not do?

- Do you have measurable fiscal gains that can be presented to the organization to show the success of RFID?

- Have you documented the business process RFID will change?

- Are you working with other vendors for an open RFID system or is this just an internal closed loop system used only in house? If it is open, document and agree on the RFID standard to be used.

Techno-Geek Stuff:

- What frequency is best suited for your environment. One size does not fit all. For example 2.4GHz is highly absorbed by liquid, so if your business is stocking drums of fluid, that frequency may not be the best choice

- Which RFID technology offers the best benefit per cost ratio for the organization

- Will the RFID readers interrogate the tags all the way to the floor and behind other objects?

-  What impact will adding RFID have to your current infrastructure?

A solid RFID partner with customer references is always recommended for any successful RFID project. I have seen RFID positively change many business models like email has transformed the RFD mailbox of the past to a pleasant memory. 

Jimmy Ray

 

 

Pat Peterson is now a Cisco Fellow

I had heard rumor of this when we worked with Pat Peterson at RSA this year.... but it is apparently official as I just saw it on our internal web page - Pat Peterson is now a Cisco Fellow!  This is a huge deal.  He is now one of only 13 Fellows.  I had joked when I introduced Pat on stage that although he is now considered a manager, he still does a lot of research and other hands on work...my statement to that effect was ‘Pat is not just a good talker - he is a doer’.   Here is a cut and paste of the announcement:

* * * *
Patrick Peterson

Peterson, director of technology for the IronPort Business Unit, is one of only 13 Cisco Fellows. The position is reserved for individuals whose contribution has materially impacted Cisco and the industry.

"Pat embodies the standards of excellence that set Cisco apart from other companies," says Nawaf Bitar, IronPort’s vice president of engineering and Peterson’s manager. "People of his caliber are what make this organization great."

Peterson joined IronPort in 2000 and played a major role in developing the company’s core business plan and strategy. As IronPort grew, he contributed in many areas, including product management, quality assurance, customer support, systems engineering, and training. Peterson played a key role in the invention and development of SenderBase and other IronPort technologies. (Cisco acquired IronPort in 2007.)

Peterson is recognized within the industry as a thought leader in messaging security, and speaks frequently at industry conferences.

He has a bachelor’s degree and a master’s degree, both in electrical engineering from Stanford University. Peterson holds patents related to antennas, radio frequency communications, and e-mail security.

* * * *
Pat is indeed a sharp guy and TechWiseTV thanks him for being a friend and contributor to the show.  Congratulations Pat! 

BTW - shameless plug...our next Security Show airs on June 26 and we feature an interview with Pat Peterson on the subject of Data Loss Prevention.  DLP was a huge topic at RSA and we will spend this show breaking down the technology available from Cisco to help get your hands around it. Hope you will join us!  Follow all the action and join us at www.mytechwisetv.com

Robb

New Podcast: Power and Cooling in the Data Center

Another interesting conversation from VoiceCon with our friends from APC. APC had a very intriguing booth with tall, dark gleaming equipment racks stuffed with lots of equipment. 

Most interesting for me? The NetBotz rack mounted appliance that offered not just environmental monitoring with detection and alerting but also an integrated camera...how cool to trip an alert with a rack is opened and then be able to immediately see who is/has opened it.  They have integrated this into some pretty nice management systems. 

There is so much to power and cooling that I never would have considered... such as shifting loads to compensate for changing demands due to virtualization.   I could see how this could be more important as both virtualization increases and the size of your data center grows.

Please to enjoy the podcast!

Mean Time Between Marketing

Reading MTBF numbers is kinda like believing you can actually catch fish with the Ronco pocket fisherman. Wow!! According to my Mean Time Between Failure data, my network gear will last for 30 years!! This number is very often misinterpreted and misused. Sorta like a furniture store going out of business for five years… Normally, most folks look at MTBF data like this; "Hmmm, a year contains 8,766 hours. My switch has a MTBF score of 292Khrs. Now, lets convert that to years. I then divide 8766/292000= a little over 33 years! The higher the MTBF score, the longer the years between failures. For example:  MTBF of 438Khrs; 8766/438000= almost 50 years (49.9). Wholly smokes!!! Whatta deal! I’ll take two!

Well of course, after concluding that the MTBF means the device will last for decades, amusingly, one of two opposite things usually happens: either the person actually thinks the device will last half a century or longer, or the opposite: they realize this is crazy and so they write off the entire MTBF figure as "obvious exaggeration and therefore useless". The real answer of course is neither. (It is obviously impossible for any individual switch to be tested to anywhere near the amount of time required to provide a MTBF factor near even 100,000, never mind 500,000.)

To be interpreted properly, I will use switches since I am at the core a Star Trek geek and a switch kinda Dude that loves to eat and fish, but not eat fish. The MTBF figure is intended to be used in conjunction with the useful service life/Annual Failure Rate of the switch, the typical amount of time before the switch enters the period where failures due to component wear-out increase. That is why I always include both numbers in any reliability calculation. MTBF only applies to the aggregate analysis of large numbers of devices it says nothing about a particular or single unit. If the MTBF of a model is 500,000 hours and the service life is five years, this means that a switch of that type is supposed to last for five years, and that of a large group of switches operating within this timeframe, on average they will accumulate 500,000 of total run time (amongst all the switches) before the first failure of any switch. Or, you can think of it this way: if you used one of these switches and replaced it every five years with another identical one, in theory it should last 57 years before failing, on average. Though I somehow doubt we'll be using 10/100/1000/10000 switches by the year 2057….. It will be cool positronic wave matrix like on Star Trek:NG. That would be cool!

There are in fact two different types of MTBF figures. When a manufacturer is introducing a new switch to the market, it obviously has not been in use in the real world, so they have no data on how the switch will perform. Still, they can't just shrug and say "beats me Dude, but buy some anyway", because many customers want to know what the reliability of the switch is likely to be. To this end, manufactures calculate what is called a theoretical MTBF figure. In marketing, this called to super awesome low failure rate… This number is based primarily upon the analysis of historical data; for example: the historical failure rate of other switches similar to the one being placed on the market, and the failure rate of the components used in the new model. It's important to realize that these MTBF figures are estimates based on a theoretical model of reality, (much like normal marketing…) and thus are limited by the constraints of that model. There are typically assumptions made for the MTBF figure to be valid: the switch must be properly installed, it must be operating within allowable environmental limits, and so on. Theoretical MTBF figures also cannot typically account for "random" or unusual conditions such as a temporary quality problem during manufacturing a particular lot of a specific type of switch.

After a particular model of switch has been in the market for a while, say a year, the actual failures of the switch can be analyzed and a calculation made to determine the switch's operational MTBF. That’s the good stuff because it has been field tested. That’s I why I tell folks to ask for the date of calculation for the switch MBTF numbers. Like the freshness date on beer. This figure is derived by analyzing field returns for a switch model and comparing them to the installed base for the model and how long the average switch in the field has been running. Operational MTBFs are typically lower than theoretical MTBFs because they include some "human element" (you know Cisco marketing is effective if you hear the song “Teenage Wasteland” in your head about now…) and "unforeseeable" problems not accounted for in theoretical MTBF. Despite being arguably more accurate, operational MTBF is rarely discussed as a reliability specification because most manufacturers don't provide it as a specification, and because most people only look at the MTBFs of new switches--for which operational figures are not yet available.

The key point to remember when looking at any MTBF figure is that it is meant to be an average, based on testing done on many switches over a smaller period of time. Despite the theoretical numbers sometimes seeming artificially high, they do have value when put in proper perspective; a switch with a much higher MTBF figure is probably going to be more reliable than one with a much lower figure, of course. As with most specifications, small differences don't account for much; given that these are theoretical numbers anyway, 350,000 is not much different than 300,000.

 

New Podcast: Visionary Communications

Cullen Jennings discusses a range of unified communications topics, including his role as a communications visionary at Cisco.

Get the podcast now!

I used to wish my MAC had a lens cap

MAC owner remotely accesses her stolen computer and uses photobooth to take a picture of the thieves using it. That same pictures leads to their arrest. Genius!

I love this story since it is so unexpected.

Should Twitter replace Q&A?

More twitter talk... Jimmy Ray and I were brainstorming how we might be able to use Twitter when a show is streaming live to get a more animated (and transparent) conversation going about the topics on a given show. For every live show, we feature a Q&A with experts that is chat based via the on24 interface. We capture that Q&A and make it available to access if you are watching the replay. Why should some of that conversation stop? Could we not make it more valuable and long lasting if we moved it to Twitter? Couple of angles to consider with this:

1. Not everyone has twitter. (This once again highlights the viral networking nature of an app like this...’please join so we can add value to each other...’)
2. Twitters are limited to 140 characters. (pro and con - be concise with your question - we will have to be concise with our replies.
3. On the pro side - the conversation is viewable by all. More than just a designated group can get in on the conversation. Expands the value I believe.

I don’t quite have it straight in my head on how to do this - I think we will just start trying it over the next few shows. You can follow both me and Jimmy Ray on twitter. We have also created a TechWiseTV twitter account to follow for use during the shows.

I wonder hashtags might give us more creative options? Still a very emerging capability... so I don’t place this high on the urgent list... more about hashtag’s here:

From the about page on the Twitter Fan Wiki:

Hashtags are a community-driven convention for adding additional context and metadata to your tweets. They're like tags on Flickr, only added inline to your post. You create a hashtag simply by prefixing a word with a hash symbol: #hashtag.

Hashtags were developed as a means to create "groupings" on Twitter, without having to change the basic service. The hash symbol is a convention borrowed primarily from IRC channels, and later from Jaiku's channels.