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 06:21 AM PST – Page Load: 0.3255 Sec.
Local Time: Tuesday, December 02, 2008 06:21 AM PST – Page Load: 0.3255 Sec.
And the one by Commissioner McDowell in the WaPo was also quite good.
BitTorrent does two strange things to ISP networks: opens an enormous number of TCP virtual circuits and puts a ton of data on the upstream path. Both require management response on shared-resource networks, and the TCP Reset is actually the only way to reduce the connection count down to something reasonable.
And if you don't like "surreptitious packet drop" you better stay off the Internet, because that's exactly the mechanism inside the network that manages congestion. It's called "Jacobson's Algorithm" and it's part of the Holy Writ.
Capacity is limited on every network, sharing the rule of the packet network, so we need to get used to the fact that we have to play well with others.
Richard Bennet claims, as he does at every opportunity…
If your network depends on there being a manageable quantity of open TCP connections, you're either using Network Address Translation, or you're doing something drastically wrong. TCP only requires the endpoints of the connection to maintain state. The intermediate routers aren't even obliged to care whether the packets are TCP or not.
I'd really rather not point out this elephant standing in the room every single time you bring it in with you, but it strikes me that some less technical parties might believe what you say if it goes unchallenged. To them I would point out that "the necessity of TCP Reset as a management technique" is one of Richard Bennet's favourite refrains, but it is not a generally accepted network management practice, and he has yet to actually explain its necessity in coherent terms.
And if Comcast were doing just that (without discriminating on the basis of application type or other such details), it's doubtful that we would be discussing them in the present context.
There are many things that need to examine session state, and NAT is certainly one of them. Flow-management gear would be another. Don't confuse the academic accounts of Internet architecture with the actually deployed architecture.
Similarly, let's not be naive about the nature of the complaints; the Neut movement isn't composed of engineers with refined preferences for one form of traffic management over another, it's a group of people with a generally sour outlook on capitalism, markets, and corporations. Not that there's anything wrong with that outlook, but you're not going to appease them with technical niceties. They want a publicly owned Internet and won't stop until they get it.
Is flow management the issue here, seriously, or is it just an irrelevant example? If flow management is the problem, then the solution would seem to be "don't do it". Why bias performance in favour of those who open many TCP connections, then sabotage them by injecting RST segments?
Yes, I'm still trying to pin you down on this whole "technical necessity" thing.
As to your ridiculous straw-man characterisation of the "Neut movement"—I'm not interested. Speak for your own point of view; if I really want to know what they want, I'll ask them.
BitTorrent is an innovate new application that presents a new and different pattern of traffic to the Internet access network relative to other applications. Therefore, it stands to reason that it might need to be managed by different means than other applications.
You can either accept that or not, Brett; or you can keep questioning me on it every time I comment on CircleID. I'm tired of answering you, so this is it.
Richard, if I weren't open to the idea that management using TCP Resets might be a reasonable idea, I would not have hammered you for specific details in such a frustrating and unfruitful exchange over such a long period. In fact, I have been extremely charitable towards your point of view, entertaining its possibility despite the fact that it flies in the face of well-established principles, recognised best practices, and opinions of experts for whom I have great respect. It would have been much simpler for me to assume that you are the disingenuous mouthpiece of an amoral telco, engaging in sophistry to justify an action as "reasonable network management" when it is no such thing. Such an assumption would have saved me a lot of typing. Instead, I chose to assume the best, and have tried to extract from you the technical details of your argument.
Although you have mentioned certain technical facets of the problem, a coherent and satisfactory argument has not been forthcoming, and it now seems that it never will be forthcoming. I'm afraid that there is a very large gap between "new applications may necessitate new management techniques", and "TCP Resets are the only way to deal with this issue". The latter is an extraordinary claim, and it does not follow from "BitTorrent is different". Extraordinary claims deserve extraordinary support, but you are disinclined to provide it, and I'm not prepared to take your word for it that such an argument exists.
It remains your unsubstantiated opinion that TCP Resets are a necessary form of traffic management for BitTorrent, despite expert opinion to the contrary, and despite the conspicuous presence of similar ISPs around the world who cope with BitTorrent traffic without resort to this technique.
I'd be a fool to consider your case any further. I agree that we should desist from further discussion.
Let's just say that no network management technique should be ruled out a priori. I'll leave it as a exercise for the student to discover the utility of TCP connection pruning.
Hello Richard and Friends:
For the record I am not sour on capitalism, markets and corporations. You should know that my work on the topic of network neutrality seeks a middle ground, nor do I accept financial sponsorship without full disclosure.
I favor better than best efforts routing. I am not an engineer, but am fully capable of smelling a rat.
I was specifically referring to the popular movement for a regulated Internet, Rob, and I don't consider you a part of it.
Am I wrong?
Yes Richard I do not support a regulated Internet. For that matter I am not sure the FCC has statutory authority to regulate the Internet. You may have heard about the concept of "ancillary jurisdiction" under Title I of the Communications Act--a regulatory application of the transitive principle: A is to B as B is to C; therefore A is to C.
Even before receiving legislative authority, the FCC regulated cable television based on its potential to harm regulated broadcasting. Absent statutory authority the FCC appears to be stretching Article I authority.
On the other hand I do not believe ISPs should have complete unilateral authority to offer and to revise "take it or leave it" service agreements. I agree with Professor Crawford that the Federal Trade Commission probably would provide a better forum to resolve service agreement issues. In light of limited broadband competition--particularly in rural locales like my zip code--I do think an ISP should have complete freedom to modify or violate contractual commitments.
I don't propose a complete free pass for ISPs, and have actually proposed a regulatory framework to the FCC. Maybe I'm more of a regulator than you are.