It just another form of Control

Traffic shaping also known as "packet shaping" is an attempt to control computer network traffic in order to optimize or guarantee performance, lower latency, and/or increase usable bandwidth by delaying packets that meet a certain criteria. Using Locustworld, traffic shaping is any action on a set of packets which imposes additional delay on those packets such that they conform to some predetermined constraint a contract or traffic profile.

Traffic shaping provides a means to control the volume of traffic being sent into a network in a specified period using bandwidth throttling, or the maximum rate at which the traffic is sent which rate is limiting. This control can be accomplished in many ways and for many reasons; however traffic shaping is always achieved by delaying packets. Traffic shaping is commonly applied at the network edges to control traffic entering the network, but can also be applied by the traffic source for example, computer or network card or by an element in the network.

Traffic policing is the distinct but related practice of packet dropping and packet marking. An example of why you want to utilize traffic shaping is providing Quality of Service (QoS.) My recent focus and interest has been improving and providing carrier class wireless network. This is partly motivated by a requirement for an Internet Protocol Quality of Service (IP QoS) solution to allow us to converge our video, voice and data networks with in the Mesh Network.

The Canadian Radio-television and Telecommunications Commission (CRTC) has been asked to investigate the impact of "traffic shaping" by Internet service providers (ISPs) on Canadian Internet users. http://www.mediacastermagazine.com/issues/ISArticle.asp?id=82157&issue=03312008

Simply put one must utilize a form of control if the goal is to provide QoS for streaming media then it is required on a share network; however, when traffic shaping is utilize to restrict the usage for non QoS application and it is utilized for non QoS but for bandwidth control then these practices and the implications for consumers should be advised appropriately. Since this practice has been utilized for years it important not to debate on traffic shaping but to debate how the consumer or client is affected by such controls. It’s funny how when you subscribe to a service for years, how the service evolves to the point that general consumers are impacted.

Doctor, Doctor

Yes Hello,

-Our plan was to bring Wi-Fi to the city using wireless mesh and we have run out of money.

What happened?

-Well we we're sure and we put to tender and RFP that we awarded. When it came to implementing we wanted to be sure that we could managed this and ensure that our customers would get the best possible service.

Then what happened?

-Well, we started to deploy and we ran into some problems.

What type of problems?

-Well we couldn't get the coverage and the bandwidth to all the people so we need to buy more equipment.

So how much did you originally budgeted for?

-We went with the lowest bidder and we ensure that we follow ITIL methodology.

Hmmm, I see and now?

-Can you help?

Did you use best practice prior to deployment?

-No?

Oh so you are paying not only for best practices but to build out a wireless mesh?

-I'm not following?

So the cost to have all the right practices far out weighed the cost of deployment?

-I suppose so.

Hmmm.

-What does that mean?

Is your Wi-Fi working today?

-Yes it great but it's like TV all those channels and nothing on. But Doctor what about the cost to deploy the remaining network.

If it is working today are you starting to see a return on investment?

Not yet.

Why do you want to continue this path?

Because this is the methodology we deployed and we can't change it now

Excuse me why I try to kiss the sky

So about 3 years ago I was really interested how municipalities would implement wifi specifically wireless mesh into cities such as Phili, San Frasisco and even my hometown Toronto. After reading the NY Times article: http://www.nytimes.com/2008/03/22/us/22wireless.html?_r=1&pagewanted=1&ref=technology&oref=slogin

I can see why all of these failed. In Toronto the idea was to get people to buy into Muni wi-fi as if it was a service provider; with Phili they didn’t use my bandwidth allocation and found out that they need more repeaters than they thought and with San Francisco well who knows.

Now if you had read about 3 years ago I really criticized the city of Toronto with the deployment of the wireless mesh using best practices, since there was not enough information on the mesh to formulate best practices or any standards around the mesh. But this blog is not about “I told you so” but for best practices using wireless mesh I know I’m right and my colleagues who have built wireless meshes all around the world do know how to deploy this successfully.

But this article is not about wireless mesh but it is about deploying an ISP. We learn from the early dial up days that deploying Internet was to oversubscribe. Today with the technology although this is still being done the over subscription model doesn’t work.

In my paper on deploying a metropolitan Internet services provider I indicated that you would need a host of services everything from VoIP, IPTV, Gaming, MTU, etc. Keeping my paths of revenue coming was the key. I guess that technology was on the Municipalities and the cost for deployment was started to become astronomical. So focusing on the main services such as applications wasn’t on people minds.

Now also I just read in Commsday web site that Wimax pioneer also said that they are too are having a problem but this time it wasn’t deployment but with the actual technology. http://www.commsday.com/node/228 Wireless is having a bad taste in people mouths because of early adopters.

Now if everyone can remember there was suppose to a wireless standard IEEE was working on. This was to ensure that everyone using wireless mesh in regardless of the type of equipment or manufacturer of that equipment. Well we are still waiting for them to ratify this technology.

Mean while the use of 802.11N and IP6 is becoming more mainstream and the early pioneers of wireless mesh or not consolidating but starting to feel the pain of the early adopters. I also started to notice a few years ago that there were instant experts on the Muni front giving consulting advice. I was very concern when I saw this for wireless mesh as the crowned so call experts hadn’t even had the experience of putting up a wireless mesh.

Now that we are going on to 5 years of hosting wireless mesh in a small corner of Toronto I can say now that the technology is sound and it time to put some standards in place that make sense.

What would I do differently? Well first to get profit you need to different streams of revenue. Lets say:

ILEC - VoIP

Cable TV using IPTV technology

Gaming site – Poker, to Xbox

Web, email, web, data transfer, VPN

Security –Video

Video Conferencing

Unified Communication

Integrated Services and Private Networks

E-commerce, Dept and Credit Card services.

Just to name a few. These are business that need to be built first they all then can be tied together using wireless mesh. The provider should either charge based on transactional basis or by flat fee. Nevertheless the establishment of commerce using this technology is paramount. Unless of course you are making a Community based wireless system and then you would need to share all the charges including depreciation of the mesh to make it work. Bottom line you need identify your revenue stream to make this work and I believe that people in Muni game may have failed to recognize this model.

Carrier Class Wireless Mesh Application for VoIP

By its architecture and topology Wireless Mesh can handle carrier class services; however, when adding and application like VoIP downtime is not an option and requires fully redundancy. Feb. 2008 I attend Toronto Asterisk User Group (TAUG) meeting. And out of the meeting was to provide a rudimentary fault tolerant system that could provide 5 9’s i.e. 99.999% uptime for Asterisk Telephony solution. Now if you have read any of the previous blog articles you can see that putting in application like Telephony into a wireless mesh will not make the application automatically fault tolerant.

The application it self requires to have some redundancy. During the meeting I was introduced to three open source products:

• Heartbeat application from www.linux-ha.org
• csync2 from oss.linbit.com/csync2/(for cluster replication
• OpenSER from www.Openser.org a loading balancing device for SIP calls

The product from OpenSER is amazing if you want to have a complete load balance fault tolerant system that can handle 5000 simultaneously this is the product. However for mesh network the Heartbeat application and csync2 application can be used for a host of different product and it is not only design for Asterisk solution using Linux but any Linux solution.

Linux-HA Heartbeat provides sophisticated high-availability failover capabilities for Linux platforms. How it works is that you have two devices that you synchronized together using csync2. This creates the master and slave of the two applications that sit on two Linux boxes.

Now Heartbeat application creates a unique IP address for the two boxes. Which everyone is the master the IP address is assign, in the event of that the master loose connectivity the IP address is reassign to the slave box. To see the actual presentation Check out TAUG will give you a better explanation.

Nevertheless both heartbeat and csysnc2 are pretty good products that can help any Linux application become fault tolerant. However, modern solutions are to have high availability load balancing with no single point of failure. For building such system check out the OpenSER.