A World Without Multicast

3... 2.. 1. Caffeine sequence initiated...We have lift off! I rolled my fat butt out of a warm bed on a cold Wisconsin morning to conduct a WebEx Workshop on "Designing Your Network For The NEW Video" to a group of engineers in India today. I think they were surprised when I told them that this is NOT a Multicasting workshop. So was I... Video has really taken a major turn in how we deploy it in our networks. Back in the olden days of 5 years ago, we used to say stuff like convergence ready for Voice Video and Data. Truthfully, that meant Voice: Yes, Data: Yes, Video: Well, based upon today's web cams and low efficiency codex...ummm sure, spelling AVVID with two V's is much cooler then just one. So engineers like me started laying out rendezvous points, learning our *,G and making heads or tails of IGMPv2 over IGMPv3. Multicast was King and life was good. Plus many other apps and routing protocols also use multicasting so it was fat city all around you know. But then a couple major things happened that changed everything... Video turned into a HD and the pictures were amazing. We started watching the Indianapolis Colts put the hurt on other NFL teams and the picture was so clear you could see a linebackers pants pop out when they farted. High quality video production tools once reserved for the deep pockets of Hollywood were now in the hands of regular folks. Videos became a hit. So much so that we integrated video cameras on cell phones and Flip cameras. Folks wanted video at all times. Don't believe me, fire up a video and see how many folks shoulder surf you to see what you are watching. Even without sound, video rules and captures attention. Just like the over used and tired line from Field of Dreams; "Get me a beer and hotdog so I watch these dudes play ball" PCs followed Mac's (insert snarky Mac elitist comment here) and came with web cams built in and now new VOIP phones have video cams built right in. Video is on your network. When it comes to planning your network for the "NEW" video please do not make the same early mistakes I made early on: - Just because your network can handle voice does not mean it is ready for video. - Don't think it's all about multicasting. Multicast play a small role in video today. - Your on video for the enjoyment of the world...all...the...time... ah college.... Here is why; an HD video transfer breaks down to simple math. In HD parameter of 1080p30 basically means that: - I have 1080 lines of horizontal resolution that are combined with 1920 lines of vertical resolution. HDTV 101 right? you can learn that from a Best Buy ad. Let's take it out farther. 1080p30 means that I have 2073600 pixels per screen. The "p" (progressive) means that every time I receive a frame each and every line is refreshed and redrawn. If you see an "i" (interlaced) that means that every other line is refreshed when I receive a frame. The "30" means that I am receiving frames at a rate of 30 per second. That's a lot of refreshing going on per second. In network planning terms putting HD on your network looks like this: 2073600 pixels * 3 Bytes (each pixel hold 3 bytes of info) * 8 bits per byte sampling * 30 frames per second = 1.5GB of information! Yowza!! something had to be done here to get this to work on a network. Enter H.264 compression. H.264 actually compresses this info from a whoppin' 1.5GB down to 5Meg! That is a 99.8% compression ratio. Kinda like those vacuum space bag things to store my old 38 Special tshirts in! Very impressive! But here is where the problems start. Ethernet by nature is a lossful medium. Normally, that is not a big deal. Heck on the best VOIP network we can work just fine with 1-3% loss of frames. Plus our personal tolerance for poor voice has went up with cell phones. Especially if you have AT&T. How much information do you think you lose in just one compressed H.264 frame? A noticeable amount for sure. One lost frame will result in screen pixelation (those little squares that pop up on an imagine). Voice is actually like a group a well trained and disciplined military troops. It's a very well behaved and predictable service. Oh sure it's time sensitive but the frames are small, constant size (for example g7.11 frame is always going to be 160 bytes plus the overhead and flow at the rate of one every 20mS), low bandwidth requirements, ect... More and more I am seeing voice networks deployed without any QoS. I do not recommend it, but folks are doing it without problems. Makes sense with pipe sizes and high speed ASICs, TCAMs in today's gear. Video on the other hand is like a preacher's kids when they leave home and go to college. They can be all easy going one minute, then nickel beer night hits and well you know the rest of the story... Video has a real "bursty" nature. The amount of information transferred depends upon how much movement is going on. When your screen goes thru a refresh cycle the minimal amount of lines you have to repaint the better. The truth lies in the math so if we are transferring 5M per second @ 30 frames per second that equals out to a frame every 33mS. BUT the amount of info transferred in a video frame depends on the movement so 33mS is an average and can burst way beyond that. Now you know why Telepresence rooms look like as sterile as they do. It has little to do with a unified experience and more to do with a bandwidth conservation methodology. What's important here: - High Availability to the MAX! We can not loose packets. Hang on to those packets like a coupon for free chicken at Popeye's!! Nothing pisses an Executive more then to look like Max Headroom on a video conference. The tolerance is 0.0-.05% loss but it is really 0.0 once you factor in that things only break when management is using it and that happens around performance eval time... For my HD networks, I run ISSU/NSF/SSO on my 4500's and VSS on my 6500 as well as StackWise+ on my edge devices. My routing protocols like EIGRP or OSPF are config'ed for sub-second recovery. I avoid STP if possible and use Multi chassis Etherchannel IF I can. OK, time to look at latency. Our target for latency is similar to that of VOIP 150mS one way. But truthfully, our range is 150-200mS one way. There are three other things to consider when working out your latency budget. Two you can not control on one you can. - Serialization: Is like trying to get your drunk cousin to leave your house, it a fixed time. This is the time it takes to convert a L2 frame into a L1 group of pulses (electro/optical) This is fixed. The important thing to know here is WHAT the serialization delay is on your gear. - Propagation Delay: This is the actually delay it takes to go from point A to point B. Basically, for you to fart, someone else to smell it and you to blame on another party. If you are planning out latency, propagation is going to be 95% of your budget. This is also beyond your control because it is a property of physics. It take 120mS for light in fiber optics to travel 15K miles. - Queuing: This is totally within our control. Queuing delay is the chief cause of jitter. This is where solid QoS planning comes into play. The two authorities on QoS planning/mapping are RFC 3246 which is a standard and RFC 4594 which is a best practice or Informational RFC. You absolutely positively must use QoS policies on a HD network. This is the ONLY area we have to influence latency since the other two are fixed. Make sure that the switches you either have or use have the nuts to support the queuing you need. Cisco list out their buffer with equations like this: 1p3q3t, 1p7q4t, etc... that breaks down to this: 1p: One single strict priority queue 3q: Thee weighted round robin queues (which break down to 70/25/5. The number must always equal 100) 3T: three trigger or weighted random early detection drop thresholds. Man alive, there is so much more to write here. Cisco Press does have a great book on this titled: Cisco Telepresence Fundamentals and some great design stuff is also located at http://www.cisco.com/go/srnd under the video section. Just keep in mind that multicast is NOT the only way to do video now. Truthfully, I am seeing more stream splitting going on now for point to multi-point video and multicast is being pushed down to a protocol handler more and more. When it is used, it is used in Source Specific Mode (SSM). I do not see multicast going away now or ever really as a stare at my USB enabled Pet Rock... Jimmy Ray Purser Trivia File Transfer Protocol Happy Birthday to You; that'll be 30 bucks or the DMCA going to get ya! AOL Time Warner owns the copyright of "Happy birthday to you" until 2030. That's why movies often use different songs for birthday scenes. AOL Time Warner earns over $2 million per year from royalties for the song. Yowza!