When I grow up I'm gonna be a bitpipe

It's only been 2 weeks since Orange and O2 in the UK displayed anger towards Nokia over the inclusion of Skype on their N97. Rumours bounced around of them throwing the rattle out of the pram and not wanting to stock the possible iphone killer.

Well I suppose it's not as bad as 96 when US telecoms companies asked congress to ban IP phones.

Since then O2 have confirmed it will not rule out stocking the handset "if the experience is right" whatever that means. Let’s see what Orange has to say in the coming weeks.

But why all the fuss?
For years mobile operators have been trying to identify themselves as something different to that of a bitpipe. But what are they actually doing about it apart from producing unintelligible adverts and creating complex price plans.

All the great new mobility services I see are developed by the likes of Google, Flickr, Twitter and Skype... the list goes on.

Application nirvana began with the synergy of handset manufactures and these very software developers, this has now exploded as the user can access these application shop fronts directly. Android market and itunes apps are already paving the way.

With Nokia's Ovi store (May 09) and similar offerings from Microsoft to follow it looks as if traditional mobile operator offerings such as voicemail and callback (any more I ask ?) will be floundering in their wake.
With Google voice hitting Beta yesterday these apps just keep coming.

Mobile operators should embrace these edge applications and see how they can work together with developers to improve their subscriber’s quality of experience.
If they expand the IP horizon as far as it will go (3GPP Rel8 anyone ?) and invest in their existing cores it should help them flourish as a proud bitpipe.

Hey they might even look to implement IPv6 but that won't become an issue until 2012 will it?

Quality of our network press

OK I like to keep up with the current trends in my industry, on occasion I look to the press for interesting articles. Sadly a lot of this is marketing fluff, misunderstood technology (researched by the gossip columnist on a quiet day?). Saying that, you can usually find a route to the real information if you look under the cover, but best of all it gives me a good laugh.

Just have a look at how the top two newsfeeds interpret the same story, the bottom one just tries to spice it up with some sexual connotations.


If anyone else has anything similar please let me know. Maybe this could be the start of my very own networking colemanballs collection.

Using Dummynet to simulate WAN links (2/2)

Thought it might be a good idea to split these sections as you only install once (Sounds like a bad Bond movie) So this part I'll deal with the operation of Dummynet:

Dummynet is contolled by the IPFW command but first we have to configure both Ethernet interfaces and set them up for bridging.

Configure both interfaces with an IP address within the same subnet (Any will do) as below:

# Ifconfig dc0 inet 192.168.0.253 netmask 255.255.255.0

# Ifconfig rl0 inet 192.168.0.252 netmask 255.255.255.0

Note: These IP address aren't actually visible to external devices, so they don't have to conform to the exiting subnet surrounding your server (It just appears as a L2 device, which the following command enables)

Then link both interfaces together so they will bridge packets rather than route them:

# sysctl –w net.link.ether.bridge.enable=1

# sysctl –w net.link.ether.bridge.config=dc0,rl0

Now we can define a firewall pipe where we can control the bandwidth and delay

# ipfw add pipe 1 ip from any to any

# ipfw pipe 1 config bw 3200Kbit/s queue 10 delay 150ms

Now check the firewall rulesets and delete any lines which have a lower value than the rules you just entered.

# ipfw show

# ipfw delete

Dummynet is now up and configured. You should be able to change bandwidth as per the ipfw pipe command shown above.

Surprisingly it's quite accurate, you can verify this yourself (always good practice) with some other tools (Future blog me thinks) and maybe an FTP server.

Using Dummynet to simulate WAN links (1/2)

OK my 1st Blog so I'll try to make it slightly interesting rather than my 1st forray into basic programming with "hello world" plastered across the screen.

There are a few network simulation tools out there, but most of these will require a six figure sum to work with. There are some good alternatives that are free. One of which is included within the Free BSD Kernel called DummyNet. If you want to simulate artificial delay, packet loss and bandwidth policing, grab yourself a spare server and follow the instructions below:

PART 1 of 2 (Installing FreeBSD and checking DummyNet options)

Dummynet is a capability that lives within the Free BSD Kernel.

Free BSD 6.2 was used in my tests and can be found at http://www.freebsd.org/where.html

After installing onto a new device with two PCI Ethernet cards the kernel was rebuilt. To see if the Kernel requires rebuilding check the file at: /usr/src/sys/i386/conf/GENERIC

See if the following options are included

OPTIONS BRIDGE

OPTIONS IPFIREWALL

OPTIONS IPFIREWALL_VERBOSE

OPTIONS IPFIREWALL_VERBOSE_LIMIT

OPTIONS DUMMYNET

OPTIONS HZ=1000

If they are not copy (cp) this file to a new file called MYKERNEL and add the above options

Change to the /usr/src directory

# cd /usr/src

Compile the kernel with

# make buildkernel KERNCONF=MYKERNEL

Install the ner kernel

# make installkernel KERNCONF=MYKERNEL

The new kernel will be copied to the /boot/kernel directory as /boot/kernel/kernel and the old kernel will be moved to /boot/kernel.old/kernel. Now, shutdown the system and reboot to use your new kernel.

Next Blog see how to apply and run.