Carrier Wi-Fi Comes of Age in 2013

All indications point to full speed ahead for service provider Wi-Fi deployments in 2013.  While Wi-Fi has been around for quite sometime as a consumer and enterprise technology, it’s never garnered the kind of attention that it will this year.

The reason? Wi-Fi is seen as the most economical and capacity-rich technology to help carriers address the tremendous acceleration in mobile data traffic –particularly within high-density areas.  Most geographies are seeing traffic growth of 50 to 100% year-on-year with no end in sight.  It is easy to do the math here and see that this will easily overwhelm the existing mobile infrastructure, even with LTE deployments.

Why Wi-Fi?  Why now?

Wi-Fi is rapidly emerging as a credible RAN (radio access network) technology that can be deployed alongside of 3G and LTE in a mobile network. Initial Wi-Fi deployments were all about offload and capacity injection. Now the future is much more about integration into the core. This enables the user to have an “always-best-connected”experience, regardless of location or radio access technology. Users won’t need to know or care about Wi-Fi authentication or roaming—it will all be as automatic and secure as in the 3G/LTE world. These charts from Infonetics’ 2012 carrier survey pretty much tell the Wi-Fi story.

That said, here are the pieces that are all coming together in 2013:

1. Device Support. In the fall of 2012, Apple joined the Android camp in moving to dual-mode smartphones. By adding 5GHz support, it opens these devices up to a huge pool of spectrum that can approach 500MHz in many geographies.  Even the largest mobile operators seldom have more than 100MHz of licensed spectrum in major cities.  This will push more and more smartphones users to look to the Wi-Fi bands to get connected.
2. Transparent Connectivity. After many years of work the industry is on track to begin commercializing Hotspot 2.0.  This makes Wi-Fi as easy to use and as secure as cellular.  Hotspot 2.0 capable APs are already shipping from the major infrastructure vendors and smartphones should emerge early in the new year. With the industry forecasting shipments of nearly a billion smartphones in 2013, and with operators and enterprises deploying Hotspot 2.0-ready infrastructure by the millions of units, this technology will rapidly sweep throughout the world.  Users will no longer have to think about SSIDs and authentication, instead Wi-Fi will just weave itself into the fabric of the world’s mobile networks.
3. Core Integration. To truly become just another mobile RAN technology, it will be necessary to backhaul traffic into the mobile packet core.  This allows subscribers to get the same set of services regardless of the radio access technology.  These services include billing (pre-paid and post), policy, lawful intercept, roaming, authentication, addressing, mobility management, content filtering, and the list goes on and on.  It even opens up the possibility of session persistence as a user moves between the 3G/LTE RANs and the Wi-Fi RAN.  The key ingredient here is Trusted WLAN Access per 3GPP standards.  This approach requires a gateway that can bridge the world of the Wi-Fi RAN to the mobile packet core.
4. High Density. Build-outs in very high-density venues continue unabated.  These are often the locations where Wi-Fi offers the most compelling solution.  These venues include stadiums, airports, arenas, convention centers, downtown city centers, college campuses, etc.   Users have now come to expect Wi-Fi when they walk into any of these locations and traditional neutral host DAS solutions just can’t scale as efficiently as Wi-Fi.
5. Making Money.  One of Wi-Fi’s great strengths is that it is easily configured as a neutral host solution.  This means the venue owner only needs to let one operator into their building, and that operator can wholesale to all other operators.  These wholesale arrangements will start to emerge in the first half of the year.  The story gets even stronger as Wi-Fi is integrated into the mobile packet core and into mobile billing systems.  It will eventually become part of the service bundle that the subscriber pays for on a monthly basis.
6. Management and Service Innovation. And no list would be complete without a discussion of management systems and new service enablement.  This is another area where the mobile world excels, and we will start to see a host of platforms emerge here that can be used for analytics, reporting, location based services, personalization, loyalty programs and more.  Location is one of those very interesting options where a host of very targeted services can be directed at the user based on their location.

Make no mistake, Wi-Fi is slated to become the third major standard RAN technology in the mobile operator portfolio.  And it looks to be the technology that will do most of the heavy lifting in the very high-density venues from where most of the traffic load is coming.

Source: http://www.theruckusroom.net/

Exadata versus IPv6

Recently one of my customers got a complaint from their DNS administrators, our Exadata’s are doing 40.000 DNS requests per minute. We like our DNS admins so we had a look into these request and what was causing them. I started with just firing up a tcpdump on one of the bonded client interfaces on a random compute node:

01	[root@dm01db01 ~]# tcpdump -i bondeth0 -s 0 port 53

02	tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

03	listening on bondeth0, link-type EN10MB (Ethernet), capture size 65535 bytes

04	15:41:04.937009 IP dm0101.domain.local.59868 > dnsserver01.domain.local:  53563+ AAAA? dm0101-vip.domain.local. (41)

05	15:41:04.937287 IP dm0101.domain.local.46672 > dnsserver01.domain.local:  44056+ PTR? 8.18.68.10.in-addr.arpa. (41)

06	15:41:04.938409 IP dnsserver01.domain.local > dm0101.domain.local.59868:  53563* 0/1/0 (116)

07	15:41:04.938457 IP dm0101.domain.local.56576 > dnsserver01.domain.local:  45733+ AAAA? dm0101-vip.domain.local.domain.local. (54)

08	15:41:04.939547 IP dnsserver01.domain.local > dm0101.domain.local.46672:  44056* 1/1/1 PTR dnsserver01.domain.local. (120)

09	15:41:04.940204 IP dnsserver01.domain.local > dm0101.domain.local.56576:  45733 NXDomain* 0/1/0 (129)

10	15:41:04.940237 IP dm0101.domain.local.9618 > dnsserver01.domain.local:  64639+ A? dm0101-vip.domain.local. (41)

11	15:41:04.941912 IP dnsserver01.domain.local > dm0101.domain.local.9618:  64639* 1/1/1 A dm0101-vip.domain.local (114)

So what are we seeing here, there are a bunch of AAAA requests to the DNS server and only one A record request. But the weirdest thing is of course the requests with the double domainname extensions. If we zoom in at those AAAA records requests we see the following, here is the request:

 

1	15:41:04.937009 IP dm0101.domain.local.59868 > dnsserver01.domain.local:  53563+ AAAA? dm0101-vip.domain.local. (41)

And here is our answer:

 

1	15:41:04.938409 IP dnsserver01.domain.local > dm0101.domain.local.59868:  53563* 0/1/0 (116)

The interesting part is in the answer of the dnsserver, in 0/1/0 the DNS server tells me that for this lookup it found  0 answer resource records, 1 authority resource records, and 0 additional resource records. So it could not resolve my VIP name in DNS. Now if we look at the A records request:

 

1	15:41:04.945697 IP dm0101.domain.local.10401 > dnsserver01.domain.local:  37808+ A? dm0101-vip.domain.local. (41)

and the answer:

 

1	15:41:04.947249 IP dnsserver01.domain.local > dm0101.domain.local.10401:  37808* 1/1/1 A dm0101-vip.domain.local (114)

Now by looking at the answer: 1/1/1 we can see that i got 1 answer record in return (the first 1), so the DNS server knows the IP for dm0101-vip.domain.local when an A record is requested. What is going on here? Well the answer is simple, AAAA records are IPv6 DNS requests, our DNS servers are not configured for IPv6 name request so it rejects these requests. So what about those weird double domain names like dm0101-vip.domain.local.domain.local? When Linux requests a DNS record the following happens:

1. Linux issues DNS request for dm0101-vip.domain.local, because IPv6 is enabled, it issues an AAAA request. 2. DNS server is not configured for IPv6 requests and discards request. 3. Linux retries the requests, looks into resolv.conf and adds domainame, we now have dm0101-vip.domain.local.domain.local 4. Once again, the DNS server discards this request. 5. Linux once agains retries the AAAA request, adds domain name: dm0101-vip.domain.local.domain.local.domain.local 6. DNS server discards AAAA request 7. Linux now falls back to a DNS IPv4 request and does an A request: dm0101-vip.domain.local 8. DNS servers understands this and replies

This happens because Exadata comes with IPv6 Enabled on both infiniband and ethernet interfaces:

 

01	[root@dm0101 ~]# ifconfig bond0;ifconfig bond1

02	bond0     Link encap:InfiniBand  HWaddr 80:00:00:48:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00

03	inet addr:192.168.100.1  Bcast:192.168.100.255  Mask:255.255.255.0

04	inet6 addr: fe80::221:2800:13f:2673/64 Scope:Link

05	UP BROADCAST RUNNING MASTER MULTICAST  MTU:65520  Metric:1

06	RX packets:226096104 errors:0 dropped:0 overruns:0 frame:0

07	TX packets:217747947 errors:0 dropped:55409 overruns:0 carrier:0

08	collisions:0 txqueuelen:0

09	RX bytes:320173078389 (298.1 GiB)  TX bytes:176752381042 (164.6 GiB)

10

11	bond1     Link encap:Ethernet  HWaddr 00:21:28:84:16:49

12	inet addr:10.18.1.10  Bcast:10.18.1.255  Mask:255.255.255.0

13	inet6 addr: fe80::221:28ff:fe84:1649/64 Scope:Link

14	UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

15	RX packets:14132063 errors:2 dropped:0 overruns:0 frame:2

16	TX packets:7334898 errors:0 dropped:0 overruns:0 carrier:0

17	collisions:0 txqueuelen:0

18	RX bytes:2420637835 (2.2 GiB)  TX bytes:3838537234 (3.5 GiB)

19

20	[root@dm0101 ~]#

Let’s disable ipv6, my client is not using on ipv6 its internal network anyway (like most companies i assume). You can edit /etc/modprobe.conf to prevent it from being loaded at boot time, add the following 2 lines modprobe.conf:

 

1	alias ipv6 off

2	install ipv6 /bin/true

Then add the below entries to /etc/sysconfig/network

 

1	IPV6INIT=no

Reboot the host and lets look at what we see after the host is up again:

 

01	[root@dm0103 ~]# cat /proc/net/if_inet6

02	00000000000000000000000000000001 01 80 10 80       lo

03	fe8000000000000002212800013f111f 08 40 20 80    bond0

04	fe80000000000000022128fffe8e5f6a 02 40 20 80     eth0

05	fe80000000000000022128fffe8e5f6b 09 40 20 80    bond1

06	[root@dm0103 ~]# ifconfig bond0;ifconfig bond1

07	bond0     Link encap:InfiniBand  HWaddr 80:00:00:48:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00

08	inet addr:192.168.100.3  Bcast:192.168.100.255  Mask:255.255.255.0

09	inet6 addr: fe80::221:2800:13f:111f/64 Scope:Link

10	UP BROADCAST RUNNING MASTER MULTICAST  MTU:65520  Metric:1

11	RX packets:318265 errors:0 dropped:0 overruns:0 frame:0

12	TX packets:268072 errors:0 dropped:16 overruns:0 carrier:0

13	collisions:0 txqueuelen:0

14	RX bytes:433056862 (412.9 MiB)  TX bytes:190905039 (182.0 MiB)

15

16	bond1     Link encap:Ethernet  HWaddr 00:21:28:8E:5F:6B

17	inet addr:10.18.1.12  Bcast:10.18.1.255  Mask:255.255.255.0

18	inet6 addr: fe80::221:28ff:fe8e:5f6b/64 Scope:Link

19	UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

20	RX packets:10256 errors:0 dropped:0 overruns:0 frame:0

21	TX packets:5215 errors:0 dropped:0 overruns:0 carrier:0

22	collisions:0 txqueuelen:0

23	RX bytes:1559169 (1.4 MiB)  TX bytes:1350653 (1.2 MiB)

24

25	[root@dm0103 ~]#

So disabling ipv6 modules through modprobe.conf did not do the trick, what did broughgt the ipv6 stack:

 

1	[root@dm0103 ~]# lsmod | grep ipv6

2	ipv6 291277 449 bonding,ib_ipoib,ib_addr,cnic

The infiniband stack brought up ipv6, we can disable ipv6 at kernel level:

 

1	root@dm0103 ~]# sysctl -a | grep net.ipv6.conf.all.disable_ipv6

2	net.ipv6.conf.all.disable_ipv6 = 0

3	[root@dm0103 ~]# echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

4	[root@dm0103 ~]# sysctl -a | grep net.ipv6.conf.all.disable_ipv6

5	net.ipv6.conf.all.disable_ipv6 = 1

6	[root@dm0103 ~]# cat /proc/net/if_inet6

7	[root@dm0103 ~]#

Now we are running this exadata compute node without ipv6, we can now check if we still have infiniband connectivity, on a cell start a ibping server and use ibstat to get the port GUID:

 

1	[root@dm01cel01 ~]# ibstat -p

2	0x00212800013ea3bf

3	0x00212800013ea3c0

4	[root@dm01cel01 ~]# ibping -S

On our ipv6 disabled host start the ibping to one of the

 

01	[root@dm0103 ~]# ibping -c 4 -v -G 0x00212800013ea3bf

02	ibwarn: [14476] ibping: Ping..

03	Pong from dm01cel01.oracle.vxcompany.local.(none) (Lid 6): time 0.148 ms

04	ibwarn: [14476] ibping: Ping..

05	Pong from dm01cel01.oracle.vxcompany.local.(none) (Lid 6): time 0.205 ms

06	ibwarn: [14476] ibping: Ping..

07	Pong from dm01cel01.oracle.vxcompany.local.(none) (Lid 6): time 0.247 ms

08	ibwarn: [14476] ibping: Ping..

09	Pong from dm01cel01.oracle.vxcompany.local.(none) (Lid 6): time 0.139 ms

10	ibwarn: [14476] report: out due signal 0

11

12	--- dm01cel01.oracle.vxcompany.local.(none) (Lid 6) ibping statistics ---

13	4 packets transmitted, 4 received, 0% packet loss, time 4001 ms

14	rtt min/avg/max = 0.139/0.184/0.247 ms

15	[root@dm0103 ~]#

So we have infiniband connectivity, lets see how Oracle reacts:

 

1	[root@dm0103 ~]# crsctl stat res -t

And now we play the waiting game… well basically it never comes back, it tries to  read from 2 network sockets if we look with strace, it hangs at:

 

1	[pid 15917] poll([{fd=3, events=POLLIN|POLLRDNORM}, {fd=4, events=POLLIN|POLLRDNORM}], 2, -1

Which points to 2 file descriptors which it can’t read from:

 

01	[root@dm0103 ~]# ls -altr /proc/15917/fd

02

total 0

03	dr-xr-xr-x 7 root root  0 Feb  3 18:37 ..

04	lrwx------ 1 root root 64 Feb  3 18:37 4 -> socket:[3447070]

05	lrwx------ 1 root root 64 Feb  3 18:37 3 -> socket:[3447069]

06	lrwx------ 1 root root 64 Feb  3 18:37 2 -> /dev/pts/0

07	lrwx------ 1 root root 64 Feb  3 18:37 1 -> /dev/pts/0

08	lrwx------ 1 root root 64 Feb  3 18:37 0 -> /dev/pts/0

09	dr-x------ 2 root root  0 Feb  3 18:37 .

10	[root@dm0103 ~]#

There is an dependency between ipv6 and CRS on an Exadata, disabling ipv6 will cripple your clusterware. There is no real solution for this problem because we need ipv6 on an Exadata, we can’t disable it. However we van easily reduce the amount of ipv6 DNS lookups by extending our /etc/hosts file and adding all hostnames, vip names etc. of all our hosts in our cluster in every single hostfile on computenodes. Unfortunately we can’t do this on our Cell servers, because oracle does not want us to go ‘messing’ with them so you have to live with it for now.

Source: http://jongsma.wordpress.com/2013/02/03/exadata-versus-ipv6/

The real Gigabit Challenge is getting ISPs to think like tech firms

 

Forget getting a gigabit in one city in all 50 states of the U.S. The real gigabit challenge is helping the existing ISPs think like innovators, not like utilities.

On Friday six cities in North Carolina issued a request for proposal for gigabit connections at a reasonable costs for businesses and residents. The cities have been talking up their efforts which would include new investment from a company, as well as the opportunity to lease the cities’ dark fiber. Just like Seattle, Chicago, Chattanooga and Bristol Tenn., and Kansas City, these North Carolina municipalities are taking their broadband future into their own hands.

As cities around the U.S. look at gigabit connections and see the future infrastructure that they ought to provide to ensure their citizens have access to 21st century jobs and remain (or maybe even become) hotbeds of innovation, FCC Chairman Julius Genachowski has also hopped on board the train. The Chairman, playing the role of chief cheerleader called for a Gigabit Challenge three weeks ago: asking that every state in the U.S. get at least one gigabit city by 2015.

The real gigabit challenge is to change the ISP mindset

But he had it wrong. No matter what the FCC does, there will be gigabit cities in most states by 2015, or those networks will be under construction.  The real gigabit challenge is to get the telcos to think like tech companies or to get them out of the way. If we accept that broadband is the silicon of the next fifty years — providing the platform for technological innovation and advancement that chips had done from 1960 on — the we need the providers of broadband to think like tech firms. Intel makes for a great example.

One of Intel’s fabrication plants.

The chip giant has consistently pushed for faster and more chips off its manufacturing lines — even when it’s manufacturing operations cost billions to build. It has never told consumers that its 486 chips would be sufficient, and then tried to control the programs that would run on them. Instead it has pushed its partners for faster software that would require faster and better chips. And it then pushed those chips into new areas such as servers. Intel delivers a commodity of sorts — the x86 platform — but it still raked in profits of $2.5 billion last year, and is even now investing up to $2 billion to change its fabrication methods to produce even more chips on larger wafers.

 

On the flip side, we have the telcos and the cable guys who generally provide most of the broadband in this country. In different eras and in different ways each has made vast technological investments in networks that can deliver broadband around the U.S. But after the after their initial investments they stopped looking ahead in many cases, or pushing their envelope. When the telcos saw the success of ISPs they bought them up. As cable providers saw the success of ISPs, they came out with their own broadband services that were faster than the DSL technology the cables had.

The broadband race ended in the mid-2000s

The 90s and early 2000s were a great time for broadband. There was competition from various providers, and differing technologies and people responded. Consumers signed up for these new services, and entrepreneurs built products that ranges from eBay and Napster all they way up to the genesis of Facebook. But then two things happened.

The first is broadband adoption slowed. Unlike telephone lines, if you had one broadband account in the home you didn’t really need another. During this time the cable companies and telcos focused on their other lines of business, adding HD channels on the cable side and putting money in wireless and additional phone features on the telco side.

The other thing that happened is the regulatory environment became pretty hands-off when it came to messing around with the Internet and regulators looked at the competition between cable and telcos as sufficient to ensure that people would get the connections they needed. But unlike a tech firm, which in the lack of regulation pushes ahead to fulfill a set vision for the world, such as gather all of the earth’s information, the telcos and cable guys just sat on their networks making money off those investments from five or ten years previous.

They didn’t pay attention to where the world was going other than to pop their heads up and lament the profits folks like Google or Amazon were making off of “their pipes.” They wanted to stand still and reap profits because that’s what utilities do. They invest in infrastructure and they maintain it. Along they way they lobby the government to ensure or keep their profits. And that’s why there are grim charts about how the cost per megabit are going up, despite the falling costs of providing a megabit.

Unlike Intel, which puts a lot of R&D in its business and hopes to sell more of its chips in more places, and so invests in technologies that drive the adoption of silicon, ISPs are implementing caps and incentives that are aimed to preventing people from using broadband — or at least second guessing themselves when they do. Should I buy a Dropcam? It uses 60 GB a month of data? Should I download the entire Lord of The Rings trilogy in HD or will that push me over my quota for the month?

A modest proposal for ISPs

If ISPs had been thinking like tech firms they would have realized that their goal was to connect everyone to the internet, deliver the Internet everywhere and invest in applications that would drive demand for faster speeds. ISPs should have beat Boingo and Wayport to the Wi-Fi hot spot business. They should look at the Internet of things and see opportunities for delivering quality of service and prioritization and create services for that. And fundamentally, they should be playing a game where they want to get to a gigabit, because if everyone wants a gigabit connection, they will have to get wireline connections for home and still have their Wi-Fi and cellular for everywhere else.

So now that the RFP for North Carolina is out, maybe we’ll see an ISP step up to the plate and think like a tech firm. There are plenty of innovations they could help drive to lower the cost of deploying such networks. Or maybe they could take a page from Google and try some social engineering. After all, that document allows the incumbent broadband providers the same ability to participate as it does for a Gigabit Squared or a Google. And if that could help get ISPs to think like tech firms, then it could benefit us all.

Source: http://gigaom.com/2013/02/03/the-real-gigabit-challenge-is-getting-isps-to-think-like-tech-firms/

Free super Wi-Fi plan stirs opposition

WASHINGTON — The federal government wants to create super Wi-Fi networks across the nation, so powerful and broad in reach that consumers could use them to make calls or surf the Internet without paying a cellphone bill.

The proposal, from the Federal Communications Commission, has rattled the $178 billion wireless industry, which has launched a fierce lobbying effort to persuade policy makers to reconsider the idea, analysts say. That has been countered by an equally intense campaign from Google, Microsoft, and other tech giants who say a free-for-all Wi-Fi service would spark an explosion of innovation and devices that would benefit most Americans, especially the poor.

The airwaves that FCC officials want to hand over to the public would be much more powerful than existing Wi-Fi networks that have become common in households. The signals could penetrate thick concrete walls and travel over hills and around trees. If all goes as planned, free access to the Web would be available in just about every metropolitan area and in many rural areas.

The new Wi-Fi networks would also have much farther reach, allowing a driverless car to communicate with a vehicle a mile away or a patient’s heart monitor to connect to a hospital on the other side of town.

If approved by the FCC, the free networks would take several years to set up. And, with no one actively managing them, connections could easily become jammed in major cities. But public Wi-Fi could allow many consumers to make free calls from their mobile phones via the Internet. The frugal-minded could even use the service in their homes, allowing them to cut off Internet bills.

‘‘For a casual user of the Web, perhaps this could replace carrier service,’’ said Jeffrey Silva, an analyst at Medley Global Advisors, a research firm. ‘‘Because it is more plentiful and there is no price tag, it could have a real appeal.’’

The plan would be a global first. When the US government made a limited amount of unlicensed airwaves available in 1985, an unexpected explosion in innovation followed. Baby monitors, garage door openers, and wireless stage microphones were created. Millions of homes now run their own wireless networks, connecting tablets, game consoles, kitchen appliances, and security systems to the Internet.

‘‘Freeing up unlicensed spectrum is a vibrantly free-market approach that offers low barriers to entry to innovators developing the technologies of the future and benefits consumers,’’ Genachowski said in a an e-mailed statement.

Some companies and cities are already moving in this direction. Google is providing free Wi-Fi to the public in the Chelsea neighborhood of Manhattan and parts of Silicon Valley.

Cities support the idea because the networks would lower costs for schools and businesses or help vacationers easily find tourist spots. Consumer advocates note the benefits to the poor.

The proposal would require local television stations and other broadcasters to sell a chunk of airwaves to the government that would be used for the public Wi-Fi networks. It is not clear whether these companies would be willing to do so.

The FCC’s plan is part of a broader strategy to repurpose swaths of the nation’s airwaves to accomplish a number of goals, including bolstering cellular networks and creating a dedicated channel for emergency responders.

Some Republican lawmakers have criticized the idea of free Wi-Fi networks, noting an auction of the airwaves would raise billions for the Treasury. That echoes arguments made by AT&T, T-Mobile, Verizon Wireless, Intel, and Qualcomm that the government should selling airwaves to businesses.

The lobbying from the cellular industry motivated longtime rivals Google and Microsoft to join forces to support the FCC’s proposal. Both would benefit from a boom in new Wi-Fi devices. They want to multiply the number of computers, robots, and other machines that connect to the Internet, analysts said. They want cars that drive themselves to have more robust Internet access.

More public Wi-Fi, they say, will spur the use of ‘‘millions of devices that will compose the coming Internet of things.’’

Source: http://bostonglobe.com/business/2013/02/04/tech-telecom-giants-take-sides-fcc-proposes-public-networks/5cx7s8HHZtod7iUqdhBMxN/story.html