Sections:
Home |
Featured Blogs |
News Briefs |
Industry Updates |
Topics |
Community
RSS Feeds, Email Updates, Mobile Edition and More: CircleID Extras
About: About CircleID | Media Coverage | CircleID Blog | Contact | Advertising Programs
Terms & Policies: Codes of Conduct | Privacy Policy | Terms of Use
RSS Feeds, Email Updates, Mobile Edition and More: CircleID Extras
About: About CircleID | Media Coverage | CircleID Blog | Contact | Advertising Programs
Terms & Policies: Codes of Conduct | Privacy Policy | Terms of Use
Copyright © 2002-2008 CircleID.
Iomemo Inc.
All rights reserved unless where otherwise noted.
Local Time: Tuesday, December 02, 2008 12:32 AM PST – Page Load: 0.4089 Sec.
Local Time: Tuesday, December 02, 2008 12:32 AM PST – Page Load: 0.4089 Sec.
This is not correct: "The AP earlier reported that Kevin Martin was going to circulate an order to the FCC fining Comcast."
The order is an enforcement action, it does not include a recommendation for a fine, nor did I report that. As for the first story that got facts "ass backwards"? Details would be appreciated.
John Dunbar
I'm constantly stunned at how badly Richard Bennett fails to get this stuff.
Comcast are currently using deep packet inspection to try to enforce network non neutralities.
It's a daft, losing strategy.
The reason it fails is because any company is outnumbered by their customers (by sheer economic necessity). That means that their customers run rings around them. Customers simply change their packets unti the DPI fails to properly categorise it. Only a strategy which *cannot* be evaded can hope to succeed.
Comcast know this; this is why they're abandoning their non neutral strategy.
DPI works, if you're working *with* the customers. If you use DPI to make VOIP packets high priority so that VOIP works well, then customers don't mind that, and if you tell them hour many hours of VOIP per week they can use, then your network doesn't break, because you can provision it accordingly; and if they go above that, you downgrade their VOIP to best effort. Everybody is happy.
It's that simple, it's about agreeing with your customers what you're going to provide and providing it. If you, Richard Bennett Network Architect (sic) don't know how to do that, then you need to leave it those who do.
Ian Woollard said:
I think you have a problem with your expectations. Richard is clearly an advocate or apologist for Comcast: his knowledge and competence are being applied to the task of making Comcast's position seem reasonable, and its opponents' positions seem unreasonable. Like a defence lawyer, his conclusions are quite foregone: "my client is innocent". The only potentially interesting part is how he reaches that conclusion from the facts themselves—or at least the claims he chooses to present as fact in argument.
This activity is normally associated with lawyers, spin doctors, and fanboys. This isn't a court, and I have no reason to think that Richard is a lawyer. It's less clear whether he's acting in the capacity of spin doctor or fanboy. I haven't seen any disclaimer or disclosure from him as relates to a possible financial interest—not that it matters much, since advocacy is advocacy whether it's paid or not.
I have all sorts of financial interests in this debate, the primary one being that I make my living doing network engineering and I don't want my profession equated with dealing drugs. That's why I've been active in the debate since 2003, three employers ago.
The essence of the net neutrality debate is that we have a group of lawyers and law professors on one side who want networks to work a certain way (based on an over-simplified view of the Internet) and on the other we have engineers and business people who understand how they actually do work and want to retain the freedom to improve the technology. In the middle are a bunch of average citizens who don't get what all the fuss is about but just want services that are fast, fair, and affordable.
There are a lot of livelihoods at stake in this debate, no less on the side of the people who stir up fear and anxiety than among anybody else.
Richard Bennett said:
For one thing, I don't recall having seen that parallel drawn before. For another thing, it's a ridiculous assertion and I don't think you ought to grace it with any kind of response beyond a derisive snort. The worst that you could say about some engineers is that they wilfully collaborate with their employers in efforts which are designed to maximise profits without being in the genuine interests of their customers (except by a twisted argument that only a spin-doctor could love). The worst such engineers are those who turn a blind eye to customer safety issues, like dangerously defective cars. Network engineers aren't generally in this category, so it's really not appropriate to accuse a conniving network engineer of being anything worse than a mendacious weasel.
Sometimes law professors get it right, and sometimes engineers are guilty of their own egregious oversimplifications. An example of that latter point springs immediately to mind, in fact.
I'm yet to read a comment from you, Brett, that puts forward a serious argument. Making personal attacks may be amusing, but it doesn't advance the debate.
The law professors who started the net neutrality campaign make a fundamental mistake in the relationship of network theory and practice. The Internet was created to facilitate experimentation in packet networking design, and its primary mode of operation has been guided from the inception by the results of the experiment. We've formulated theories, carried out experiments, and recorded the results in RFCs, especially in Best Current Practice documents. As new applications come on-line, new challenges appear for the transport and network protocols, and revisions of practice come about.
The lawyers tend to view RFCs as they would books of legal code, a source of precedent that should bind present and future behavior by network operators; as a compass, in effect.
But for those of us who are working engineers, the RFCs are more like a seismograph that records where we've been. The experiment is ongoing, and will most likely never come to an end as long as the Internet is a functioning, operational entity.
We currently have to deal with the issue of P2P applications which, by design, consume great amounts of bandwidth for long periods of time. This is a different pattern of consumption than we've seen previously, and it needs a novel management response. The IETF is working on the problem in the P2PI working group. There is no RFC that says how P2P should be handled right now, so a large set of options are on the table.
The lawyers never comment on the fact that this pattern of consumption is unique; rather, they blindly criticize management of over-consumption as if it took place in a vacuum.
A balanced debate needs input from both sides, and the input needs to be intelligent. I'm trying to achieve that balance.
What are you doing to advance the debate on Internet management?
Comment removed by CircleID Admin as per Codes of Conduct.
In a recent Blog Maverick post, Mark Cuban said:
If you have a serious point to argue, Ian (AKA Wolfkeeper, etc.) make an argument for it instead of hiding behind personal attacks, slurs, and lazy insults.
In fact, DPI has already given way to Traffic Stream Analysis in the packet classification systems used by Comcast and the other ISPs. These systems operate on traffic characteristics that can't readily be spoofed or obfuscated, because they represent stream parameters: number of streams, stream lifetime, and volume of data in the streams. The so-called DPI systems (which never were all that deep) triggered on port numbers and protocol IDs, and were simply an easy way of classifying traffic for prioritization purposes; so easy, they've been in universal use in interior routers since the late 80's as they're essential to make Jacobson's Algorithm avoid its annoying tendency to cycle.
Nonsense posing and philosophizing may wash in Wikipedia-land, but it's not good enough to cut the mustard on this site, Ian.
Traffic analysis? Good thing there's no known ways to tackle that like 'Traffic flow security'. That was invented in WWII. What could go wrong?
Really, as soon as you start treating your own customers like they were the enemy in WWII then your business is going down. Network non-neutralities are inherently customer-hostile, but customers aren't stupid, they talk to each other and they will often abandon service providers using it at the first opportunity.
Richard Bennett wrote:
The lack of a "serious argument" on my part is explained by the fact that I'm not trying to advocate a particular viewpoint. Rather, I'm trying to understand the problem as a whole. I do not intend to launch a personal attack, but when you make ludicrously overbroad claims of fact, such as framing the debate as being between "lawyers and law professors" with an "over-simplified view of the Internet" on one side, and "engineers and business people who understand how they actually do work and want to retain the freedom to improve the technology" on the other, I will point out the irony of your own over-simplification. I'm sure there are many network engineers who resent the suggestion that they are simplistic if they don't agree with you, and there may even be some law professors who are insulted for the converse reason. Whatever the case, it's pretty rich that you're criticising my lack of contribution to the debate while you're engaging in this level of rhetoric.
As to the remainder of your comment, I won't dwell on your straw-man characterisation of a law professor and his lack of understanding; rather, I'll try to address the technical issues. I invested quite a bit of effort in understanding your position on a previous occasion, and I still haven't reached a satisfactory understanding of why RST injection is technically superior to packet dropping. That's the meat and potatoes of this debate, and I'm quite willing to focus on it, but it hasn't proved very fruitful in the past.
You make all sorts of claims as to the uniqueness of this situation and how the RST injection approach is fundamentally necessary, and so on. I don't wish to assert that the old principles are fundamental laws of nature, but I do think that the burden of proof should be on those (such as you) who claim that the new situation of peer-to-peer file sharing warrants an adjustment to well-established principles. Several of those principles are related and inter-woven: the dumb network principle; the end-to-end principle; the layering principle. The practice of inserting RSTs into a TCP stream on an application-oriented basis flies directly in the face of all of these. I want compelling evidence that the traditional remedy of application-agnostic packet dropping is not good enough.
I do believe that Comcast has a network management problem, and they have chosen to address it with the RST-oriented approach. I see no need to invoke black helicopters and conspiracy theories. (I could be wrong, but I don't want to cloud the technical issues if I am.) I also accept your earlier assertions that this network management problem relates to the DOCSIS architecture. I still do not accept that the use of RSTs constitutes a technically superior solution to the problem—although I do accept that it constitutes a technically expedient solution. You have presented a great many words in support of your argument that the RST approach is necessary, or at least superior. I have found those arguments lacking, and refer you to our previous discussions on the matter (linked above) for the details.
The argument over technical superiority raises the separate question of whether ISPs ought to employ application-neutral network management techniques in general, or whether it's fair to interfere with the application that's causing them the most difficulty. This latter question is where the law professors have an entirely valid point to raise within their own area of expertise. If we allow network management techniques to interfere with specific applications, we invite the service providers to sabotage those applications which most threaten their particular business models, under the pretext of "reasonable network management". Such anti-competitive behaviour is not in the interests of consumers no matter how much "reasonable network management" wrapping adorns it.
Here's part of an e-mail I got the other day from Larry Roberts, the designer of ARPANET, that helps explain the problem, Brett:
"...P2P expands to fill any capacity. In fact, as I have been testing and modeling P2P I find it taking up even higher fractions of the capacity as the total capacity expands. This is because each P2P app. can get more capacity and it is designed to take all it can. In the Universities we have measured, the P2P grows to between 95-98% of their Internet usage. It does this by reducing the rate per flow lower and lower, which by virtue of the current network design where all flows get equal capacity, drives the average rate per flow for average users down to their rate. They then win by virtue of having more flows, up to 1000 per user. I suspect they do not do this on cable since the upstream capacity is only 10 Mbps and when it saturates, they must stop at about 80%. But raise the capacity per user and the capacity of the upstream choke point and watch out! P2P can consume virtually any capacity.
Larry"
I hope that clears it up.
This is a re-statement of the problem, not an explanation. Furthermore, this re-statement seems to be slightly different to the problem we have already discussed: it does not mention the DOCSIS upstream congestion problem, and seems to exclude cable modems generally ("I suspect they do not do this on cable"). There are numerous other questions I could raise about this explanation, but they are of lesser importance than the lack of a clear problem statement, and I don't want to cloud the issue.
I'm afraid this has not made matters any clearer, Richard. A proper explanation starts with a very clear problem statement and works through to a solution, step by step. In this case, the explanation must also show why the novel network management technique (RST injection) is superior to the traditional approach (packet dropping). I thought we'd reached a firm problem statement, but this attempt at explanation has thrown that back into doubt.
Here's a rough outline of the problem as I understand it so far. P2P protocols tend to degrade network performance for other applications. How? At this point I'm not sure how to continue, because I'm no longer sure if the problem is one of DOCSIS upstream congestion, subversion of router traffic management policies, or maybe both.
Brett,
I'm not sure if I'm reading you right, but I sense that you have a bit of doubt that the P2P problem actually exists. Trust me, it does. The behavior of the protocols and the traffic they generate are staggering. They are like a virus. A few users can generate so much traffic that they completely step on all "regular" subscribers and overwhelm the network. In a DOCSIS-based broadband platform I worked on, even traditional bandwidth management appliances that partitioned and rate-shaped traffic based on traditional QoS parameters were not sufficient to address the issue; we were forced to pull them out and put in P-Cube (now Cisco SCE) appliances that specialize in P2P throttling. They work, and they work well. The issue is more evident in the DOCSIS world because DOCSIS is a shared system up to the head end, not unlike an old Ethernet hub or even a TDMA-based system. DOCSIS uses a scheduler to assign timeslots designating when subscribers can transmit. Since this was years ago, it's been a while since I looked deeply into DOCSIS so I'll have to look back on notes to give you more insight on the DOCSIS aspect, but it really doesn't matter. The P2P problem could exist on a DSL network, although it would not occur on the last mile to the subscriber but rather on backbone links just past the DSLAM and aggregator. It also could occur on any corporate network, at the Internet gateways or even uplinks in between if the traffic were bad enough. Again, it is common in DOCSIS because of the shared nature of the cable Internet architecture up to the head end. We basically came to the conclusion that in any scheduler based system, you had no choice but to perform traffic shaping, else your entire service goes down the drain and you may as well shut it down.
One thing that is not clear is exactly how Comcast has their appliances (I think they are Sandvine) configured. They may be throttling in both directions. The one thing that is configurable in the appliances is to just limit or block P2P in the upstream direction (from the end user towards the Internet), since that bandwidth is more scarce. This way you can discourage the P2P protocols from allowing others out on the Internet to pull files from the cable subscribers and wrecking the upstream, while allowing the cable subscribers to download from others out on the Internet (but not from cable subscribers on the same segment.)
Again, as I've said in other posts, what is missing from this entire Comcast / traffic shaping / network neutrality debate is a common understanding of the principles behind oversubcription, which governs our phone lines, cellular phones, previously dial-up Internet access and now broadband Internet access. Without oversubscription, you would not be paying $40/month for the equivalent of a T1 to your home. The business model doesn't work. (Even the non-technical lawyers and law professors should be able to understand this.) If service providers had to truly guarantee the maximum bandwidth 24x7, they may as well be selling leased lines to the home, and those lines would be at a much higher price. If the FCC pushes too hard on broadband providers, we may very well end up with usage (per-MB) based service, which would be a disaster for most subscribers. The free market is a better way to pass judgement on the practices and service quality of a service provider. If enough subscribers drop them for a competitor, it might convince them to alter their practice or, in the case of Comcast, expedite their upgrade to DOCSIS 3.0. In the meantime, I would rather continue to pay a mere $40/month and refrain from file sharing, while permitting Comcast to throttle file sharers around me, rather than have per-MB or much higher priced service.
I don't doubt that P2P is posing a problem. I don't doubt that it creates a lot of traffic. What I doubt is that this traffic pattern is so unique as to demand "traffic shaping" techniques which involve selectively killing TCP sessions in a manner unprecedented except for its use as a denial of service attack or censorship tool.
When I first heard that Comcast was using forged TCP RSTs to address this issue, my reaction was like that of many other people: "that's not traffic management, that's sabotage”. I was initially baffled as to why they would do this. I've since reached the conclusion that the problem is P2P traffic, and they are using this ghastly hack of a management tool because it was available immediately, and had the desired effect. (Well, almost the desired effect. They clearly didn't anticipate the public relations impact.)
Richard Bennet has been trying to persuade us that the RST injection method is not an ugly hack, but quite necessary given the nature of the problem. He claims that traditional traffic shaping techniques involving selective packet drop simply do not work. My interest is network protocols rather than network management, and if his claim is true, it may impact my work quite significantly. This is why I have been trying to pin down the exact nature of the problem and the alleged need for RST segments. His assertions challenge some fairly fundamental principles of packet network design.
Frankly, if Richard is right, it exposes a much deeper problem: the P2P protocol designers can always switch to a UDP-based system which simply has no concept of "RST", and what traffic management techniques can be applied then? I'm still highly sceptical that RST injection has any merit as a traffic shaping tool from an engineer's perspective, however.
Actually, what's missing from this debate is an ability to focus on one issue at a time. Your other post is a veritable smorgasbord of issues, guaranteeing that no progress will be made on the matter as people argue directly past each other on entirely different points, and switch focus the moment that it seems like a convenient tactical manoeuvre. Yes, I realise that there is more than one issue on the table here, but do try to keep them somewhat separate unless you actually intend to hinder progress. Communication is hard at the best of times. We are simple creatures and need to simplify our problems before we can solve them.
I believe consumers pay for a certain amount of Bandwidth already. Shouldn't we be able to use the Bandwidth as we see fit? Here's a simple analogy. A casino must have enough cash onsite to cover all bets on the casino floor. Shouldn't an ISP like Comcast have enough Bandwidth/Infrastructure to support the advertised Bandwidth if all customers are concurrently using all of their connections' Bandwidth?
No. There would be no economy of scale worth mentioning if that were the case, and most of their network capacity would be wasted most of the time. This is the point: roughly speaking, you only need enough network capacity to cope with peak actual demand, and this is rarely anywhere near the theoretical maximum demand that could be placed on the network if all users simultaneously drove their connections to the limit.
Of course, you can run into a problem when you sell your services as "unlimited", and too many people start to take you at your word. It's kind of like being an "all you can eat" buffet, and having a busload of Homer Simpson clones turn up. "Unlimited" is a draw-card, but it has its risks. If you were running the "all you can eat buffet", what would your strategy be? Would you change your pricing plan away from the "unlimited" model, or poison some of the food enough to make people ill and cut down demand?