Network and Telecom Strategies Blog

WiMAX Arrives in Chicago

2009-11-02T07:00:09-08:00

Posted by: Michael Disabato

Clearwire began selling it's 4G WiMAX service yesterday. For $35 a month you get "10 times faster than 3G" (we'll see about that), and a dongle. It's not everywhere, and it's new. I'll be interested in trying it out myself and hearing from you about your experiences.

Clearwire is attempting to get laptop manufacturers to embed the electronics for that. I still maintain having any cellular radio other than GSM on a mother board is a BAD idea. Especially if it's locked to one carrier. Better the external antennas and contracts.

Michael

Congestion Going Into Network Branches = Packet Loss

2009-10-31T10:38:08-07:00

Posted by: Eric Siegel

End of the month, and I've been going over the list of the "dialogues" I had with Burton Group clients to see if there's something that might be of general interest.

So I uncovered one that I participated in with my colleague Ken Agress of Burton Group's consulting organization, and it's interesting because I think that the topic of QoS congestion on links into remote branches isn't given enough consideration in QoS network design.

The basic symptom of the problem was that despite QoS on the routers, there was excessive packet loss on high-priority flows into the branches on a hub-and-spoke network design.

But that's because the server-room router was trying to push too much data into the network cloud for a specific branch office. The discards weren't occurring at the server room boundary router into the cloud, because the fat access link from the server room will easily accommodate lots of traffic to the branch, especially if the other branches aren't receiving much traffic at that time.

If you have a large bandwidth access link into a cloud, but just a small bandwidth access link out of the cloud to a branch office destination, the cloud will need to discard data packets on high-bandwidth flows or during bursts, because the cloud itself (i.e., the backbone routers) has minimal buffering.

True, a single TCP flow will self-adjust (by "self-clocking") to a bandwidth-restricted exit from the cloud because its acknowledgements will be delayed, but if there are a lot of parallel flows, or there are non-flow-controlled UDP flows, you'll be in trouble. TCP flows will get the "global synchronization problem," in which all TCP flows ramp up in bandwidth concurrently, lose packets concurrently, reset their flow rates downwards concurrently, and then repeat. RED or WRED or FRED mechanisms can help avoid global synchronization, but you'll still lose packets.

So, how should this be handled? If you own the cloud or can signal to the cloud's administrator (e.g., by setting DSCP fields or EXP tags on packets going into a MPLS cloud), then the cloud can pick which packets to discard if the exit bandwidth isn't sufficient at the branch office. And the tags will, we hope, tell the cloud to discard packets from low-importance flows. RED / WRED / FRED on those flows will then get those low-importance flows to cut their bandwidth use. Those low-importance flows will be losing packets and will be miserable, but the higher-importance flows will get through.

A better idea, we think, is to avoid letting the cloud do your packet discards -- especially if you don't actually own/administer the cloud directly. Don't give it more traffic than it can handle; use traffic shaping on subinterface definitions to ensure that you never feed more data into the cloud than can exit at the destination. You will probably do a better job of discriminating among flow types and of smoothing brief traffic spikes (e.g., your routers probably have larger buffers than the cloud's routers have).

For example, see the following Cisco documents:

Regulating Packet Flow Using Traffic Shaping

Applying QoS Features to Ethernet Subinterfaces

Or you could install a Blue Coat PacketShaper in the server room's exit path to do the traffic shaping for both TCP and UDP. And the new PacketShapers can also do compression.

Polycom vs. Cisco

2009-10-30T13:23:19-07:00

posted by: Mark Cortner

The last month has seen several interesting developments impacting enterprise video with much of the attention being focused on Cisco’s proposed acquisition of Tandberg. But with less fanfare (at least to this point), Polycom has contributed several significant announcements of their own that may mute potential defections to the “new” Cisco video portfolio.

The acquisition of Tandberg by Cisco will add several key products which are well aligned with its vision for visual collaboration—most notably in the areas of desktop videoconferencing and especially high-density, high-definition multipoint conferencing through the best-in-class Codian product. But the recent announcement by Polycom regarding its new RMX 4000 multipoint conferencing platform is an effective a counterpunch to Codian and enables hundreds of simultaneous HD videoconferencing sessions and supports more than a thousand standard-definition video and audio conferencing sessions.

The introduction of the RMX 4000 will enable Polycom to not only address and facilitate the expanded use of visual collaboration within large enterprises but should also pause some of the advances Cisco has made over the past year with the carrier community. The market conflict driven by UC continues, I expect some (many?) enterprises may struggle with the ramifications of Cisco’s pending acquisition of Tandberg. I’m sure Polycom is preparing for the new competitive landscape in videoconferencing and this announcement is a nice addition to its arsenal.

Good News for Wideband Voice

2009-10-30T12:12:47-07:00

posted by: Mark Cortner

The recent announcement by Verizon that it will deliver all of next-generation network multimedia content over its IP-based core network, facilitating the convergence of fixed and wireless networks, is good news for wideband voice technology. The voice market is attempting the ride the wave of hype and interest in high-definition technology with the wideband voice although several practical implementation obstacles currently limit the benefits and value of wideband voice.

The fact that a significant proportion of voice calls sourced from enterprise telephony systems must traverse the PSTN for call completion renders the use of wideband voice to intra-enterprise participants is one obstacle. In addition, the use of mobile phones is increasingly common within the enterprise—many users utilize simultaneous ring, mobile extension, and mobile UC client capabilities provided in conjunction with an enterprise’s IP-PBX system to receive calls on their mobile phones instead of their desktop handsets. The impact of both of these use case scenarios diminishes the effective use and benefits of wideband voice.

The announcement from Verizon indicates that the function of network transport and media transcoding will be separated; if any media transcoding is required the primary responsibility will fall to the participating endpoints—the network will provide a media conversion function only in cases where the endpoints do not share a common codec. If the wideband voice community can convince the fixed network and wireless network endpoint vendors (nimble) to support wideband voice, the networks (not so nimble) most commonly utilized to transport voice traffic to business partners, customers, and in many cases an enterprise’s own employees, will no longer be an impediment to the use of wideband voice.

UC 1.0 – The Contrarian View

2009-10-30T10:53:43-07:00

posted by: Mark Cortner

The enterprise response to today’s UC offerings (“UC 1.0”) has generally been tepid, no doubt in part to the difficult global economy. I recognize that there is a lot of energy in the market, sourced primarily by the vendor community, though I have not witnessed a corresponding drive to invest by our enterprise clients. The reality is that although many enterprises are interested in UC and are developing technology and platform strategies, the vast majority of investment to date has been constrained to legacy refresh initiatives with an eye to ensuring that current investments do not conflict with evolving to UC.

The UC has not developed a clear or compelling message with respect to business value to date. The benefits of service cost reduction and improving the efficiency of individual and group communications and collaboration are appealing but not convincing. CEBP is very promising but still too immature to drive UC adoption. IMHO, the UC market will continue to advance at a relatively slow pace until several disruptive forces can combine and enable “UC 2.0”.

The disruptive force will not be defined solely by the presence-based integration of the communication and collaboration applications (UC 1.0); significant impacts driven by the consumerization, democratization, and externalization of enterprise IT will combine and source the magnitude of disruptive forces required for UC to succeed. The formula for each business will undoubtedly be different although similarities will exist within vertical industries. The leading candidates to drive this disruption? The most likely prospects will be driven by wireless and mobility, the viability of cloud-based UC to complement and extend enterprise-based infrastructure and applications, and ultimately ... CEBP.

UC and Virtualization

2009-10-30T09:31:31-07:00

posted by: Mark Cortner

The recent announcement from Avaya related to its new virtualized UC offering is an interesting development for the UC industry. The single-server UC solution is based on Avaya’s Aura architecture which was introduced earlier this year. In early 2008, Mitel announced a single-server solution that signified the first application of virtualization technology to enterprise real-time communications applications.

Avaya’s initial virtualization solution, Aura System Platform, is currently targeted to the midsize market with a maximum scalability of 2400 users. The solution includes the core components within Avaya’s Aura architecture—Communications Manager, Voice Messaging, SIP Enablement Services, Application Enablement Services, Utility Services, and Media Services deployed on a single server.

I fully expect more announcements soon from the UC industry that take advantage of virtualization for not only asynchronous applications but also real-time communications and collaboration applications. I also expect the scalability of virtualized UC solutions to rapidly increase; anticipate that single-server offerings will evolve to effectively address enterprise requirements within the next year … and one step closer to cloud-based UC.

AT&T and the coverage game

2009-10-30T06:22:17-07:00

Posted by: Michael Disabato

Our daughter, my wife, and I all have iPhones. They are all 3Gs and, except for memory size, all the same. So why do we all have different signal levels when they are in the same room in the same house? Good question, and one that AT&T has failed to answer after numerous phone calls. What they did tell us was interesting and serves to underscore just how badly their network is operating.

After having her 4th dropped call in one hour (so much for advertising), Daughter called AT&T and was politely insistent that the problem be resolved. The customer service rep (CSR) had her try the usual things (reboot phone, move to another location, etc.) to no avail. All this time, I'm sitting in my office with 5 bars on my phone and listening to this. Somewhere along the 30 minute mark, the CSR tells her she can have a free repeater for the house, and my ears perk up. Free? Repeater? Say what? Before I could tell her to get more info, she wrangled 2 months free service and hung up. (At this point, my iPhone showed "No Service." Go figure.)

But there it is out in the open. AT&T will give you a free repeater to solve connection problems in your home. Now I don't know if this is a femtocell or a real repeater similar to those made by SpotWave and other companies, and it doesn't matter. AT&T will GIVE you hardware to solve THEIR network problems. This is more like it.

Those of you in similar situations might want to press your AT&T CSRs to see what can be done for your home coverage. In light of the potential pandemic, you can never have too many connectivity options.

Michael

Finding the Hot Spots

2009-10-28T11:39:55-07:00

Posted by: Michael Disabato

No, not that kind of hot spot...

I found this blurb in a press release from Verizon:

"Verizon will begin requiring hardware manufacturers to use thermal
modeling when designing circuit boards and cabinets used in network
gear. The goal is to minimize heat generation that impairs equipment
performance and requires costly air conditioning in central offices,
equipment vaults and other facilities. "

How many of you are doing thermal characterization of your equipment in you data centers and closets to maximize cooling flow and minimize heat generation? Cable placement can have a significant impact on these things, so the move to Converged Enhanced Ethernet will have an impact as InfiniBand and Fibre Channel give way to a single transport.

The focus on this matter becomes more intense as more equipment is jammed into already crowded spaces. Start working with your equipment vendors the way Verizon is and start mandating more efficient hardware.

Michael

IPv6 - The boy who cried wolf…

2009-10-26T10:55:59-07:00

Posted by: Michael Disabato

ARIN and the other registries have been claiming for years that we are going to run out of IPv4 addresses. Unfortunately, their predictions were either so far into the future as to be dismissed, or readjusted because of technological advances (CDIR is one). However, late next year, that all changes as the wolf actually arrives.

I’ve been watching the predictions for the last six or seven years, and the one fault I’ve seen is not accounting for the acceleration effect of technologies, such as mobility. As a result, while ARIN claims the last block of IPv4 addresses will be given to an ISP late in 2011, I think it will be a year earlier than that. No matter. As has been said, “The jig is up.”

Assume you can’t get a block of IPv4 addresses in 3 years. What do you do? By then I hope you have done all the following:

Enable your Internet services (web, mail, etc.) to be IPv6 and IPv4. Make sure you can safely communicate with both Internet islands.
Begin testing IPv6 on your laptops. Even if you never adopt it internally, IPv6 will one day be required for hotspot access as ISPs run out of IPv4 addresses.
Check your Microsoft Server 2008 implementations. They are already using link-local IPv6 addresses for background communications.
Plan for migration to IPv6, but wait until the business case arrives (if it ever does).

Eventually, the Internet will bifurcate into IPv4 and IPv6 islands. You need to be ready to communicate with both. Further, there will come a time when you simply cannot access the Internet without an IPv6 address on your machine, and that will have security as well as connectivity issues.

Start planning now. IPv6 is imminent. And this time, we mean it.

Michael

Security on Internet Substitution Paths

2009-10-26T10:33:53-07:00

Posted by: Eric Siegel

I recently had a question come up about the security of a path that crosses the public Internet from one enterprise location to another; i.e., an "Internet substitution" path. These types of connections can be much less expensive and faster to provision than a leased line, but auditors may question their security.

Standard encryption devices can be installed at both ends of the communications path to ensure that traffic on that particular path won't be compromised, and if the Internet connection appears to your encryption devices as a simple leased line (i.e., a circuit-switch, not a packet-switch), then there shouldn't be any difference between the security situation for the Internet or for a leased line.

However, if the Internet connection appears at the encryption device's outside interface as a packet-switched, IP-based connection, then there are further considerations:

First, the encryption devices must positively authenticate each other before opening the encrypted tunnel between them.

Second, no non-tunneled traffic can be allowed to cross the encryption device. It must act as a firewall, absolutely stopping any traffic that isn't a part of the authenticated, encrypted tunnel. (This function could also be performed by the Internet interface device, but it's easier to guarantee the security of the system if it's the encryption device that's performing this function.)

Third, there must be no way that an intruder from the Internet can alter the configuration of the encryption device to subvert the firewall, authentication, or encryption functions. Ideally, the encryption box shouldn't have an Internet-accessible control address and shouldn't be discoverable by scanning. If there is an Internet-accessible control address, it must be very tightly controlled.

(Thanks to Ken Agress, of Burton Group's consulting organization, and to Eric Maiwald of Burton Group's Security and Risk Management Strategies, for assistance on this blog entry!)