PHS300 & CTR350 WiPipe (QoS) featureset?

mfisch · EVDO User Joined: 17 Dec 2007 Posts: 27

I'm a freelance network engineer and like to keep up on new tech (and I happen to be an EVDO user too).

I've been watching the cradlepoint press releases and reviews for an analysis of the WiPipe featureset but it all seems to be anecdotal remarks or copy and paste. It seems like the work Cradlepoint has done on WiPipe could be the feature that makes EVDO routers a killer-app, but I'd like to know more.

Can anyone comment on their experiences with this? Any VoIP users out there?

I don't generally work in the wireless carrier space, but from my rough understanding of Qualcomm's CDMA technology VoIP CAN work fine if implemented correctly. Please correct my understanding if anyone knows otherwise. I don't have access to specifications since they are proprietary and require expensive licensing.

An EVDO channel takes up roughly 1.25MHz of bandwidth. This is quite a bit considering the available spectrum -- but thats what gives us our 3G speeds. Since there isn't nearly enough bandwidth for us all to get 1.25MHz slices of the air Qualcomm has implemented a timesharing routine where a few hundred timeslices are doled out on an as-needed basis. Mobile phone calls, iDEN (push to talk), videoconferencing, and probably IPTV/music streaming all get priority airtime (in a designated order), the leftovers is what we all use for EVDO downloads.

If you set ping to run every 0.25 seconds to your upstream HA you'll notice ping times hopping back and forth and sometimes staying steady. This "jitter" is the result of our traffic being pushed to the back burner -- when services that can't afford to be delayed need airtime, services that can be delayed (TCP) are. Contrary to popular belief it is this jitter that makes VoIP unstable (not latency). While 50-100ms differences in packet return times might not make much a difference with TCP where a large window size and SACK allows for delays such as this, VoIP doesn't fair so well.

Now my question. I think it's fairly obvious Cradlepoint takes one of two approaches:

A) WiPipe doesn't do anything special at all but ensure outgoing traffic is classed in such a way to queue priority traffic ahead of normal fair-queue.
This in fact can be simulated on any PC with the right firewall setup. (Though quite cumbersome to the uninitiated).

B) WiPipe takes advantage of the priority status CDMA allows some traffic in the air and on the network.
They could be tagging outgoing packets with DiffServ (Differentiated Services) information (reverse engineering or licensing the proper codes from Sprint/Verizon's networks).
They could also be reserving time on the network using IntServ (Integrated Services) RSVP signaling.
They may even be grabbing prime air-timeslices using Radio Bearer QoS signaling (TSB-58-G spec?).

I understand this is "proprietary" and Cradlepoint doesn't want to help their competitors get any freebie's, but this is all information any network engineer can infer (and I could determine if I had demo hardware in front of me).

Cradlepoint? Anyone want to chime in? I'm really interested how your product works and how well it works.

Now back to the not-so-tech side of things.

It'd be really great if I had access to full documentation and screen dumps of the config pages to explore the featureset too. I understand I get this when I buy, but I don't buy blackbox mysteryware. Hey Mike/3gstore techs, can you post the documentation or is it copy-protected? I ask everyone else to refrain from posting documentation if cradlepoint/3gstore doesn't want it posted.

I'm also curious (and this is a question only Cradlepoint can answer) if some EVDO devices take better advantage of WiPipe than others, and how sprint/verizon compare. It's possible some cards do not support radio bearer signaling, it's also possible sprint/verizon have their QoS configured differently or do not allow EVDO data cards to request priority network time.

Please reply with your experiences, objective measurements or anecdotal comments welcome!

-Matt

gregh2000 · EVDO User Joined: 24 Oct 2007 Posts: 40

Well I switched from a Dlink 450 router with a px500 pc card to the cradlepoint 350 with a sierra 595u and I can tell you that overall it seems to be quicker and smoother with the cradlepoint. Also using the t-mobile at home service on the dlink worked some of the time but the call would get broken up and sped up and slowed down. The cradlepoint handles the call a lot better and there are far fewer problems. Still not perfect but it is probably sprint's fault not the router. The only problem is I can't tell if it is the router or my aircard since the px500 doesn't work with the cradlepoint and the 595u doesn't work with the dlink, lol.

mfisch · EVDO User Joined: 17 Dec 2007 Posts: 27

Anyone else?

Hardware · EVDO Heavy User Joined: 07 Dec 2007 Posts: 141

Huh...well you pretty much just asked them to tell you all their intellectual property...so I doubt you're getting that.

Your a network engineer, get us CTR350 users a set of tests to run instead of just asking CradlePoint to lift up their skirt?

mfisch · EVDO User Joined: 17 Dec 2007 Posts: 27

A document detailing the featureset would be a good step in the right direction. They do not even post specifications, screen dumps or documentation online.

As far as "lifting their skirt" so to speak. This is not true at all. All their competitors will know how they do what they do as soon as they get their hands on a unit -- this does not mean they are any closer to copying the design since it requires extensive software integration to execute. Integrated QoS signalling is difficult to implement no matter who you are, and letting us know what they did would make the product equally as impressive.

QoS is no trade secret, it is just unusual in a consumer product (it devalues much more expensive products). It is also unusual because it devalues the carrier mobile minutes -- if everyone can use VoIP why would they pay the carrier for talktime and obsurd long distance/roaming rates? On the other hand it is an unstoppable wave and the only thing the carrier can do is delay it.

The 3GPP and 3GPP2 specs from Qualcomm lay out very clearly how to implement QoS on the network in several ways. I'm also fairly certain Verizon and Sprint release additional specifications to licensed partners (cisco/linksys in the case of sprint).

There really are no easy tests to know how they do what they do that I can describe to a layman since we do not have access to the network between the Cradlepoint and the Sprint/Verizon edge routers.

Here's a few tests I can suggest, but since I don't have documentation I don't even know if they apply.

You'll want to run each test through the cradlepoint and with the EVDO interface directly connected to your PC. Also, when running through the cradlepoint use the WAN/ethernet interface if you can, otherwise ensure the cradlepoint is 3-6ft from your PC (so theres more 802.11 signal). You'll also want to turn off any microwaves, cellphones or wireless headsets/handsets in the vicinity.

First test, TCP performance:

Go to an NDT server* (you must have java enabled and your firewall turned off). Click "start". Run this three times and average the top two upload/download speeds.

* East Coast: http://jlab4.jlab.org:7123/
* Mid-West: http://miranda.ctd.anl.gov:7123/
* West Coast: http://netspeed.stanford.edu/

Click "more details". Choose copy and paste the section that looks like this:

bw = 932.52 based on packet size = 10Kbits, RTT = 11.29msec, and loss = 1.0E-6
The theoretical network limit is 932.52 Mbps
The transmit buffer (125.0 KByte) limits the application to 86.49 Mbps
Your receive buffer (63.0 KByte) limits the application to 44.28 Mbps
The network based flow control limits the application to 44.76 Mbps

Click "statistics" Copy and paste the section that looks like this:

Web100 reports the Round trip time = 11.29 msec; the Packet size = 1380 Bytes; and
No packet loss - but packets arrived out-of-order 12.60% of the time
This connection is receiver limited 98.83% of the time.
Increasing the current receive buffer (63.0 KB) will improve performance
This connection is network limited 1.12% of the time.

Next test, UDP VoIP performance (skype):

Go into preferences and enable "display technical call info".
Call "echo123", let the test run through. At the end of the call leave the call info box open and review the information. Run this test a few times and choose the median (not the best) result. Paste the section that looks like this:

Jitter: 71
Packet loss: 0.4% (14)
Send packet loss: 0.0%/0.0%
Recv packet loss: 4.5%/4.5%
Roundtrip: 108ms

I'll be happy to explain the results after you submit.

Capt Ron · Posted: Thu Jan 03, 2008 2:27 pm Post subject:

bw = 18.90 based on packet size = 10Kbits, RTT = 556.90msec, and loss = 1.0E-6
The theoretical network limit is 18.90 Mbps
The transmit buffer (125.0 KByte) limits the application to 1.75 Mbps
Your receive buffer (31.0 KByte) limits the application to 0.44 Mbps
The network based flow control limits the application to 0.24

MbpsWeb100 reports the Round trip time = 556.90 msec; the Packet size = 1380 Bytes; and
No packet loss was observed.
This connection is network limited 99.97% of the time.
Contact your local network administrator to report a network problem

The biggest problems are the ping times. As you can see they vary a lot.

Target Name: jlab4.jlab.org
IP: 192.70.245.102
Date/Time: 1/3/2008 3:57:51 PM

1 0 ms 0 ms 0 ms 1 ms [192.168.0.1]
2 149 ms 135 ms 771 ms 175 ms h28.107.97.209.ip.alltel.net [209.97.107.28]
3 138 ms 130 ms 842 ms 164 ms h54.111.97.209.ip.alltel.net [209.97.111.54]
4 142 ms 99 ms 810 ms 132 ms so-6-0.hsa2.Atlanta1.Level3.net [4.79.226.37]
5 131 ms 94 ms 778 ms 136 ms ae-31-55.ebr1.Atlanta2.Level3.net [4.68.103.158]
6 142 ms 169 ms 795 ms 104 ms ae-1-100.ebr2.Atlanta2.Level3.net [4.69.132.34]
7 154 ms 189 ms 768 ms 166 ms ae-3.ebr2.Chicago1.Level3.net [4.69.132.73]
8 295 ms 184 ms 736 ms 170 ms ae-24-56.car4.Chicago1.Level3.net [4.68.101.168]
9 196 ms 153 ms 704 ms 133 ms eqx-chi-level3.es.net [198.125.140.237]
10 203 ms 167 ms 687 ms 134 ms chislsdn1-eqxchirt1.es.net [134.55.218.82]
11 174 ms N/A N/A 137 ms chislmr1-chislsdn1.es.net [134.55.219.26]
12 165 ms 112 ms 638 ms 131 ms chicsdn1-chislmr1-2.es.net [134.55.218.89]
13 168 ms 285 ms 607 ms 120 ms washsdn1-chicsdn1.es.net [134.55.218.98]
14 * * * * [-]
15 * * * * [-]

Destination not reached in 35 hops

Sorry don't use the connection for voice.
_________________
Ron

mfisch · EVDO User Joined: 17 Dec 2007 Posts: 27

Sorry for the delay, I did not receive the topic notification.

Can you run both that test again twice (once through the cradlepoint, and once directly connected)? Also please include the upload/download speed reported on the main window.

It would be really great if you could get those numbers re: skype because it is just this traffic the cradlepoint's wipipe technology would target -- and because we'll be able to compare it to your TCP performance (the jlab ndt test).

Skype is a free download and registration, and the 'echo123' test call service is also free. You don't even need speakers and a microphone attached to get these statistics. The test call will run through in less than a minute and at the end you'll have statistics.