DCMA Section 202, Sub-Section 512, Paragraph (a) provides for common carrier status in all but name.
It does nothing of the kind, unless if by "all but name" you really mean "that it limits the liability of copyright infringement for service providers without any of the pesky regulations otherwise imposed on common carriers." ISPs derive their protections against liability of customer content from the CDA and (as you point out) the DMCA. However, ISPs are not subject to mandatory regulation under Title II of the Communications Act. TheFCC, Congress, and thecourts all agree that ISPs are NOT common carriers.
Every year or so somebody else proposes to "fix TCP". It never happens. Why?
1) TCP works well. 2) TCP is in a lot of code and cannot easily be replaced 3) If you need something else, alternatives are there, e.g. UDP, RTSP and others.
Especially 3) is the killer. Applications that need it are already using other protocols. This article, like so many similar ones before it, is just hot air by somebody that did either not do their homework or want attention without deserving it. No. There have been many changes to TCP that have gained traction. A recent example is CUBIC-TCP, a modified TCP congestion control algorithm that is showing strong adoption in newer Linux kernels.
While TCP performs well in many scenarios, it is known to perform poorly in many other scenarios. This is especially evident on wireless networks where TCP misinterprets noise-induced loses as congestion. The alternatives that you mention (UDP and RTSP) are not suitable, as they require applications to re-implement many of the desirable features of TCP, like in-order delivery, adaptation of offered-load, and end-to-end reliability. Also, many changes to TCP behavior happen completely in kernel-space and require no application changes to utilize the new features.
The real difficulty in changing TCP is that TCP is so well established. Any changes must provide a clear benefit for adopters while not breaking communication with non-adopters. *This* is what kills many proposed TCP changes, as the authors of many proposed changes make the erroneous assumptions that their change can be rolled out to the entire network all at once or that everyone even wants their changes. For example, why should users with wired connections introduce changes that will decrease their own performance so that wireless users can correctly discriminate between noise and congestion? In general, they shouldn't. Changes that actually improve the performance for those who install them tend to be the ones that are adopted widely.
They are the intended behavior of the protocol stack. Are P2P applications gaming the system by opening multiple streams between each pair of endpoints? No.
Surely you can't be serious. ("and don't call me Shirley.") Using multiple parallel TCP streams for a single application between a single pair of end-hosts to gain a competitive advantage on a bottleneck link certainly does not achieve the fairness intended for TCP. Any application doing this is clearly gaming the system. That said, the author of the article does seem to conflate this issue to unfairly vilify even well-behaved P2P applications. A separate TCP connection for each pair of hosts in communication is simply unavoidable, and the author's claim that this pairwise behavior is unfair is disingenuous.
If you're going to do it interactively, why not use a hash of the URL (or the domain name/port) instead of sending the URL itself? Then even with live checking, google would only know which sites you went to if they were a match in their list of bad guys. Not necessarily. Google could create a hash of every URL that they index (or at least the interesting ones), and then create a reverse lookup table from those hash values. They would then know much more about your browsing habits than simply which phishing sites you happen upon.
When the military DOESN'T do what the civilians tell them, you have a military coop, and I am reasonably certain you would rather have the military continue to follow bullshit directives from idiot civilians that you can replace democratically than have to deal with a military coop (which by the way would probably rather quick once you opted to quit paying them).
They've already got commissaries, why would the military open their own community run supermarkets?
Slashdot Mirror
1) TCP works well.
2) TCP is in a lot of code and cannot easily be replaced
3) If you need something else, alternatives are there, e.g. UDP, RTSP and others.
Especially 3) is the killer. Applications that need it are already using other protocols. This article, like so many similar ones before it, is just hot air by somebody that did either not do their homework or want attention without deserving it. No. There have been many changes to TCP that have gained traction. A recent example is CUBIC-TCP, a modified TCP congestion control algorithm that is showing strong adoption in newer Linux kernels.
While TCP performs well in many scenarios, it is known to perform poorly in many other scenarios. This is especially evident on wireless networks where TCP misinterprets noise-induced loses as congestion. The alternatives that you mention (UDP and RTSP) are not suitable, as they require applications to re-implement many of the desirable features of TCP, like in-order delivery, adaptation of offered-load, and end-to-end reliability. Also, many changes to TCP behavior happen completely in kernel-space and require no application changes to utilize the new features.
The real difficulty in changing TCP is that TCP is so well established. Any changes must provide a clear benefit for adopters while not breaking communication with non-adopters. *This* is what kills many proposed TCP changes, as the authors of many proposed changes make the erroneous assumptions that their change can be rolled out to the entire network all at once or that everyone even wants their changes. For example, why should users with wired connections introduce changes that will decrease their own performance so that wireless users can correctly discriminate between noise and congestion? In general, they shouldn't. Changes that actually improve the performance for those who install them tend to be the ones that are adopted widely.
Oh, maybe you meant "a military coup"...