<<   <   Page 2 / 4   >   >>
cnwedit 12/5/2012 | 4:57:24 PM
re: Broadband Is a Commodity

This one was more specific - it compared real speeds with advertised speeds. Going back to what Craig said in his first post on this string, Cablevision may be advertising blazing fast speeds and just not quite living up to that. And their customers may not know or care.

Have they boosted their advertised speeds to compete with FiOS?

paolo.franzoi 12/5/2012 | 4:57:22 PM
re: Broadband Is a Commodity


Don't know much about GPON as it was deployed but in fact the traffic on the access links was really in ATM cells per second in BPON. &nbsp;We had a magic formula (called the Moshe Mix) that allocated packet sizes so that we could map Packets to Cells to Frames. &nbsp;In a download version with lots of large packets, that mix would be off and their would be more than 100% bandwidth allocated.



Duh! 12/5/2012 | 4:57:22 PM
re: Broadband Is a Commodity

I'm going to have to sit down with the report and understand their methodology better.&nbsp; A couple of points, though.

First of all, remember this is Best Effort service.&nbsp; There is no advertized minimum rate.&nbsp; The advertized rate is the rate cap, which is enforced by a&nbsp; non-work conserving scheduler, policer or shaper in the CMTS, DSLAM or OLT,&nbsp; and possibly by a policer or shaper in the CM, DSL modem or ONT.&nbsp; The measured performance speaks to how the network is traffic engineered, and as well as aggregate load.

Rate measurement is kind of fuzzy.&nbsp; Unlike, say, Frame Relay, the advertized speed is not specified in terms of a burst size.&nbsp; So the degree to which&nbsp; measured performance tracks advertized performance depends on whether the measurement methodology uses the same burst size/time constant that was assumed by the equipment implementor.

The fact that FiOS achieved higher than advertized rates is more than a little odd.&nbsp; I've got to suspect some kind of measurement artifact resulting from the test methodology.&nbsp;&nbsp; It could be that the OLT is underpolicing based on the mix of packet sizes and packet timing. Would be interesting to compare BPON (ATM forwarding) and GPON (Ethernet forwarding) deployments on this.&nbsp;

I strongly suspect that performance is highly geography dependent, particularly for HFC, where node sizes vary greatly within a company and region.&nbsp; I'm wondering how this study took that into account.

In any event, this item has shown up as an AP story.&nbsp; Which will inevitably fan the fires of FiOS envy.&nbsp;&nbsp;

Jeff Baumgartner 12/5/2012 | 4:57:22 PM
re: Broadband Is a Commodity

They were the first US MSO to cross the 100-meg barrier&nbsp; in the downstream (bursts of up to 101Mbit/s) in April 2009.. it gave them some bragging rights among MSOs , but it was widely viewed as a competitve punch against FiOS. JB

unbearable 12/5/2012 | 4:57:21 PM
re: Broadband Is a Commodity

The reason Verizon/Fios scores so well is simple.

They underpromise and overdeliver - because they can.

Verizon is the shining example of what we can expect when we take the gloves off, and get the government out of the way.&nbsp;&nbsp; They were willing to take the risk, make the heavy investment in fiber-optics, while everyone else went on the cheap, and surprise - Americans are willing to pay a premium for stellar service.




MMQoS 12/5/2012 | 4:57:19 PM
re: Broadband Is a Commodity

Unbearable says "and get the government out of the way."

Unb, read the history.&nbsp; The "government" read FCC encouraged the Tri-BOC including Verizon, SBC and Bell So. to build FTTH and not have to share it with ALECs.&nbsp; Mr. Free Enterprise and recent CEO of GM Ed Whittaker decided to not serve his customers, even given the FCC allowances but to instead invest in acquisitions and turn lit fiber dark at the expense of his customers.

I applaud Ivan Sidenberg and the BoD of Verizon for moving ahead with FTTH while SBC acquired BS and ATT and dumbed them down.&nbsp;

Time will tell which BOC survives the onslaught of the MSOs with increased fiber penetration and improved VoIP.&nbsp; If Verizon does not come to my area, I too will become "Infinite" soon.&nbsp;

cnwedit 12/5/2012 | 4:57:18 PM
re: Broadband Is a Commodity

Speaking first to the last rant, I realize broadband is an adjective but it has also become a noun. Sorry&nbsp; - but Google is a proper noun that became a verb. That stuff happens.

I don't know how sophisticated the FCC testing was, using SamKnows, but one of the things they purported to study was how well streaming video and VoIP work on the current services, and that would seem to go beyond the blasting of large packet streams.

fgoldstein 12/5/2012 | 4:57:18 PM
re: Broadband Is a Commodity

Schools across America are suffering from excessive use of standradized testing.&nbsp; They no longer need to educate children; they merely need good test scores.&nbsp; If they aren't good enough with erasers (teachers fixing answer sheets after the fact), then they teach to the test.&nbsp; So if it can't be tested multiple-choice, it's not taught. Stuff like thinking and critical reasoning.

This has a possible analogy in these "broadband" speed tests.&nbsp; Most are simply blasting streams of large packets and counting them.&nbsp;&nbsp;&nbsp; This isn't the real world. It is the one "application" that is helped by excessive buffering.&nbsp; In almost every other case, large buffers break things.&nbsp; They screw up TCP's lame implicit congestion control hack and break any other attempt to monitor congestion.&nbsp; This "bifferbloat" is bad for everyone and everything except speed tests.&nbsp; So if we're going to rate providers based on these tests, we're going to encourage bufferbloat and the resulting bad performance in the real world.

And on a separate rant,

Broadband is an adjective, not a noun.&nbsp; Stop using it without an associated noun.&nbsp; It is a bad .

Duh! 12/5/2012 | 4:57:15 PM
re: Broadband Is a Commodity


I think I understand what you were trying to do, and I'd have done it differently.

The problem is well known:&nbsp; since (except for ATM) the unit of transmission (a variable length packet) is not the same as the unit of measurement (bytes, bits or, in your case 48 byte cell payloads), a policer or shaper will often run into a quantization error.&nbsp; In terms of a token bucket shaper, you reach a point that there is a positive number of tokens available, but fewer than the size of the next packet.&nbsp; So the choices are to drop (and overpolice); forward, zero out token count (and underpolice); forward, "borrow" tokens by making the token count negative (and underpolice).&nbsp; Or you can "softly" shape by deferring forwarding until enough tokens are available, but limit queue depth and drop when it's clear that the flow is non-conforming.&nbsp; The latter is my preferred approach.&nbsp;&nbsp; This is one of the things that was simplified by fixed sized cells.

Since it appears you were enforcing at a packet level to achieve a limit that was specified at a cell level through your magic formula, you added an additional level of quantization error.&nbsp; I'd guess that a flow that was heavily weighted to short packets would suffer overpolicing.

Duh! 12/5/2012 | 4:57:15 PM
re: Broadband Is a Commodity

So I read the report.&nbsp; Will get to the appendices if I get a chance.

It is notoriously difficult to design meaningful measurements of service rate for best effort services.&nbsp; Too many moving parts and hidden assumptions, and trying to create a measurement normalized to bits/s for a service that naturally operates on RTT and loss rate is an exercise in futility.&nbsp; I've banged my head against this a few times, and was never happy with the conclusions I reached.&nbsp; So I don't have a very good solution either.

But the measurements are a bit odd.&nbsp; They test "sustained [download|upload] speed" by doing three concurrent TCP transfers over&nbsp; a randomized interval of 25-30 seconds.&nbsp; First of all, probable "impedence mismatch" between this measurement and the rate cap enforcement mechanism in the network equipment is going to lead to some interesting measurement artifacts.&nbsp; Second, TCP is highly sensitive to RTT, including both queueing and fixed (mostly prop) delays, so variations in physical distance from the "white box" test equipment had to influence the measurement.&nbsp;&nbsp; If the measurement started when the transfer commenced, rather than when TCP transitioned to Congestion Avoidance,&nbsp; effect of Slow Start would tend to reduce measured speed regardless of available capacity.&nbsp; I'm also not convinced that these very long TCP transfers - on the order of 35 Mbytes - are representative of very much end user traffic.&nbsp; I've seen transfer size distributions somewhere, but can't remember where.&nbsp; And the fact that they're opening three TCP sessions creates all kinds of opportunity for artifacts.

Then they test "burst [download|upload] speed" by doing the same thing, but over an interval of 0-5 seconds.&nbsp; Other than testing out PowerBoost, I'm not sure what that buys. However, transfers of this size are probably more representative of end user traffic distributions.

They test "UDP latency", effectively as an end-to-end ping.&nbsp; That is a useful measurement from a technologist perspective, since it has a tremendous effect on TCP performance.&nbsp; However, it's not an advertized performance number, and it's done over a long interval.&nbsp;

It's odd that they don't also test packet loss ratio. This is the other key factor in TCP performance.&nbsp; Equally to the point, since the real "speed limit" is asserted by dropping packets,&nbsp; increasing transmission rate up to a pre-determined loss threshold (like 1e-6)&nbsp; would determine the effective open loop rate limit.

The report makes the interesting observation (see Chart 10) that speeds above about 10 Mbit/s offer diminishing returns for ordinary web browsing.&nbsp; I've speculated on this forum about the same thing, but wasn't able to tie it to a particular service rate.

Overall, this is not the best network science I've ever seen.


<<   <   Page 2 / 4   >   >>
Sign In