Make no mistake -- the Internet WILL kill newsprint. Relying on a simplistic interpretation of history isn't going to save it.
Radio didn't kill print because it didn't satisfy the same needs that print did. TV didn't kill print because it didn't satisfy the same needs that print did. Now ask yourself: does the web satisfy the same needs that print does? It's clear to me (and basically everyone else that's under 50-years-old) that it does. Not only does it replace print, but it improves on it.
I agree with McDowell with one giant exception: the laissez-faire approach will only work if there is competition in the last mile. Given that most people only have 1 or 2 choices (huge telecom and/or huge cable company), I really don't think the conditions warrant a completely hands-off approach by the FCC. Once I have several high-speed ISP options, then I'll agree with him.
Also, does anyone know what exactly Mr. McDowell is referring to when he talks about the Internet bandwidth crisis and solution of 1987?
What planet are you from?!?! Who cares if they deliver 100's of channels if none of them work?
There's a difference between "lockups, stuttering, etc..." and lowering the bitrate. One has lost data, the other just has lower quality. When the tech told you that the bad connection was "limiting the bandwidth", he was probably referring to the fact that a certain high percentage of data was getting corrupted on the line.
I understand what you're saying, but I still think it's true that most people would prefer two so-so channels over one "high-def" channel, especially when it comes to broadcast TV.
You're right, though, that people don't understand the issues surrounding compression. That will somewhat change over time. There's one thing that would create immediate change, though: being able to easily see the average bitrate of a given channel on your TV. That would turn "quality" into an easily grasped (though admittedly very imperfect) number.
My example was about an NBC affiliate that converted to the new cameras just a few months ago. I get the impression that we're talking about the same station.:)
The difference between 480p and 1080i is exactly as large as I think it is, because I see it every night on TV. This station has only converted its studio cameras, not its field cameras, so you get to see the difference between the two every minute or two.
Yes, even after compression, 1080 is still 1080. You need to stop confusing resolution with quality -- although a higher resolution will potentially look sharper, it has nothing to do with the concept of compression quality.
I was referring more to local broadcasters than to cable or satellite operators, though the principle still applies.
It all reminds me of the rage over higher frequencies in CPUs: people would usually buy a 2.4 Ghz processor instead of a 2.0 Ghz, even though the 2.0 may actually be faster. Why? Because 2.4 is more marketable than 2.0.
Huh? You mean Stargate Atlantis is being broadcast on changing resolutions in midstream?
No, it has changing quality, not resolution. They can dynamically adjust how compressed the program is from one second to another. It's still 1080i, just more or less blocky.
The only companies that can switch to MPEG4 are those that provide a set-top box to their customers (i.e. cable and satellite). That's because all HDTVs are MPEG2-only -- you have to decode the MPEG4 outside of the TV if you want to use it.
A local TV station had been broadcasting in "HD" for several years and promoted the hell out of it. Indeed, they sent out a widescreen picture, and my HDTV reported it as being "1080i".
However, the dirty little secret was that all of their cameras were 480p; they were upconverting it to 1080i right before they sent it out the door. Sure, when you watched network programming it was real HD, but all of the local newscasts were really standard-definition despite their claims to the contrary. An experienced HDTV viewer could easily see the difference, but most people had no idea.
I completely disagree -- each company should get to decide how to allocate their bandwidth. I would prefer to have two channels of good content instead of a single channel, and I'll bet that most consumers would agree with me. There's a reason why they advertise quantity instead of quality -- it's what people actually care about.
Of course, there's a point where most people DO care about quality -- stuffing 15 sub-channels into a 19 Mbps broadcast channel is going to piss people off -- but you probably aren't going to hit that point with just 2-3 channels.
A related example: I have a friend that bought a HUGE 1080p HDTV. He loved to talk about how great things looked on it. He bragged one day about how great a certain nature show looked on his TV -- until I pointed out to him that it was a 4:3 show that the TV was stretching to 16:9. He never would have known if I hadn't told him.
He fails to mention battery packs for RAID cards. They maintain power to the disk cache memory on the card in the event of a power failure, which allows the card to finish writing the cache to disk once main power is up again. That's one of the arguments for a hardware RAID solution.
Yes, SSL is about encryption. That's why the signing issue is important -- without it, you are vulnerable to man-in-the-middle attacks, which effectively negates the encryption.
Unless you've been on the road, I don't think you should be assuming that.
Not so -- there is quite a bit of photographic evidence that shows a lack of signage. Is it conclusive? No, but it's enough to make assumptions on a Slashdot comment board.
I'm sure the lawyer knows the trespass laws, and wouldn't have included it unless that law was violated.
I couldn't help but laugh a bit at his solution. He talks about "flow management" being put into the core of the network to solve TCP's unfairness problem, but at the end of the article he says:
Although the multi-flow unfairness that P2P uses remains, flow management gives us a simple solution to this: Control each flow so that the total traffic to each IP address (home) is equally and fairly distributed no matter how many flows they use.
So, in other words, his solution to the "P2P problem" is just a fancy version of a token bucket.
But I don't see what the cost for bandwidth has to do with this. If 5% of the users on a network are the "bandwidth hogs," and the ISP moves to a pay per meg model, then it stands to reason that the "hogs" will begin to use less bandwidth, or move to a friendlier environment. Either way, that's money that the ISP will no longer receive.
Don't mistake revenue for profit. If 5% of your users drop your service, you'll lose a small portion of your revenue but perhaps post a larger profit if you can then also cut your bandwidth costs in half.
but in the end, I definitely see users surfing less if they have to pay more for it.
Of course, but you're ignoring the typical usage pricing model: the regular price covers a large "base" amount of data transfer. This is essentially a hybrid model, where you only pay per megabyte when you use an extremely unusual amount of bandwidth. For example, my ISP does exactly this: I get 100 GB per month that I can use, and overages cost me extra. I am not a typical user -- I occasionally download large ISO's, for example, and I don't use P2P software -- but I have never been hit with an overage charge. I've gotten to the point where I don't even check my ISP's usage report; I'm very confident that I won't hit the 100 GB mark any time soon. Thus, my surfing and downloading habits haven't changed a bit.
And, for what it's worth, bandwidth pricing isn't much of a secret. Sure, some larger companies can get lower pricing on larger pipes, but that's the whole point of bulk purchasing.
Yes, bandwidth pricing isn't a big secret if you're talking about a small or mid-sized ISP. What about Level 3 or Comcast, though? These are the kinds of companies that are actually laying new fiber, both locally and nationally, and the cost of the resulting bandwidth isn't always simple to figure out. In addition, peering relationships between the national ISP's can be a delicate thing (depending on the ISP's involved), and a huge P2P user base on a certain ISP may force them to actually pay for some of that peering instead of getting it for "free". Those ISP's with national backbones have a much more complex bandwidth picture than Joe's ISP Shack that's run out of a basement somewhere.
This doesn't even touch on what seems to be the cable companies' real problem, though: the fact that you share your connection with a few hundred other people in your neighborhood. This means that high usage in a neighborhood can make the connection seem slow even if there is plenty of bandwidth past the cable head end, which necessitates expanding the infrastructure in the local neighborhoods.
The problem is, the ISP suddenly realizes, to their horror, that profits have gone down!
Do you have any research (i.e. real numbers) that would support this claim? I doubt it, since in order to know this, you would need to know how much the ISP pays for bandwidth, which tends to be a complex and closely guarded secret.
Humm, I am now thinking. Is there some way to detect if your on a wireless link? WiFi or any other types?
It's much more complicated than that. The P4P paper highlighted that the fundamental issue for the ISP is not distance or latency -- it's just about costs. So, in the BT case they pointed out, the best peers from a user's latency situation are not necessarily the best ones from an ISP's cost situation, and vice versa. If a P2P client wants to help their ISP reduce costs (and thus neuter the ISP's fundamental P2P objections), they simply need more information from the ISP about which network paths are more preferred than others. I'm not convinced that the P4P proposal is the best way to do that, but it's an interesting idea.
They could very well just bill per simultaneous TCP connection on which uploads exceed downloads.
Yeah, I guess they could do that, though I don't think it would be effective: a P2P client actively tries to saturate its download capability, and most consumer connections have a much higher download speed than upload speed. Thus, you would probably only "catch" a small number of P2P users, it would have a high false positive rate, and it introduces quite a bit of new billing complexity.
I much prefer the simple approach: bill by excessive usage. So long as the ISP is perfectly clear what the caps are, what the penalties are, and provide a way for the users to check their usage, I'm fine with it. Of course, there is another huge flaw -- a typical lack of competition in the "last-mile" market -- but that's another discussion.
For example, in a wireless
network where P2P nodes communicate through a base station,
peering using local peers sharing the same base station
may require more wireless bandwidth than through the base
station to other non-local peers. As another example, a common
issue exists in UK is that network providers buy their
DSL "last mile" connectivity via a BT central pipe. More
specifically, BT owns all of the exchange equipment and
connectivity between a DSL customer and a central hand-off
location. The connectivity from a DSL customer to its network
provider is first routed through BT to a physical handoff
point. The hand-off point between BT and the network
provider is what BT terms a BT central pipe. This connection
can be many orders of magnitude more expensive than
IP transit. Thus, it can be much more expensive for a network
provider to have a customer retrieve a file from another
customer on its network, than it is to go off the network for
the file.
On the other side, P2P should be given the means to hug the edges of the network.
This actually isn't always a great solution, from a cost perspective. Slashdot recently had an article that talked about P4P, which allowed ISP's to give P2P clients bandwidth policy hints -- the article pointed out that it can sometimes cost an ISP much, much more to transfer data between customers than out to the general internet. It specifically mentioned ISP's that ran on top of BT's infrastructure, but I imagine it would be similar for some DSL providers in the US.
No, its expecting the ISP to live up to its side of the contract... either way is fine, but they have to follow their agreement.
Are you saying that your ISP isn't living up to its contract with you? You don't need anything fancy to fix that -- just file a lawsuit. If they truly promised you unlimited bandwidth (as you interpret it), then you should easily win.
On the other hand, you might not completely understand your contract, and thus would take a serious beating in court. Either way, you need to accept the harsh reality that any ISP that offers broadband service (1+ Mbps) without transfer caps will go out of business within 2 years.
Slashdot Mirror
Make no mistake -- the Internet WILL kill newsprint. Relying on a simplistic interpretation of history isn't going to save it.
Radio didn't kill print because it didn't satisfy the same needs that print did. TV didn't kill print because it didn't satisfy the same needs that print did. Now ask yourself: does the web satisfy the same needs that print does? It's clear to me (and basically everyone else that's under 50-years-old) that it does. Not only does it replace print, but it improves on it.
I agree with McDowell with one giant exception: the laissez-faire approach will only work if there is competition in the last mile. Given that most people only have 1 or 2 choices (huge telecom and/or huge cable company), I really don't think the conditions warrant a completely hands-off approach by the FCC. Once I have several high-speed ISP options, then I'll agree with him.
Also, does anyone know what exactly Mr. McDowell is referring to when he talks about the Internet bandwidth crisis and solution of 1987?
There's a difference between "lockups, stuttering, etc..." and lowering the bitrate. One has lost data, the other just has lower quality. When the tech told you that the bad connection was "limiting the bandwidth", he was probably referring to the fact that a certain high percentage of data was getting corrupted on the line.
I understand what you're saying, but I still think it's true that most people would prefer two so-so channels over one "high-def" channel, especially when it comes to broadcast TV.
You're right, though, that people don't understand the issues surrounding compression. That will somewhat change over time. There's one thing that would create immediate change, though: being able to easily see the average bitrate of a given channel on your TV. That would turn "quality" into an easily grasped (though admittedly very imperfect) number.
My example was about an NBC affiliate that converted to the new cameras just a few months ago. I get the impression that we're talking about the same station. :)
The difference between 480p and 1080i is exactly as large as I think it is, because I see it every night on TV. This station has only converted its studio cameras, not its field cameras, so you get to see the difference between the two every minute or two.
Yes, even after compression, 1080 is still 1080. You need to stop confusing resolution with quality -- although a higher resolution will potentially look sharper, it has nothing to do with the concept of compression quality.
I was referring more to local broadcasters than to cable or satellite operators, though the principle still applies.
It all reminds me of the rage over higher frequencies in CPUs: people would usually buy a 2.4 Ghz processor instead of a 2.0 Ghz, even though the 2.0 may actually be faster. Why? Because 2.4 is more marketable than 2.0.
No, it has changing quality, not resolution. They can dynamically adjust how compressed the program is from one second to another. It's still 1080i, just more or less blocky.
The only companies that can switch to MPEG4 are those that provide a set-top box to their customers (i.e. cable and satellite). That's because all HDTVs are MPEG2-only -- you have to decode the MPEG4 outside of the TV if you want to use it.
A local TV station had been broadcasting in "HD" for several years and promoted the hell out of it. Indeed, they sent out a widescreen picture, and my HDTV reported it as being "1080i".
However, the dirty little secret was that all of their cameras were 480p; they were upconverting it to 1080i right before they sent it out the door. Sure, when you watched network programming it was real HD, but all of the local newscasts were really standard-definition despite their claims to the contrary. An experienced HDTV viewer could easily see the difference, but most people had no idea.
I completely disagree -- each company should get to decide how to allocate their bandwidth. I would prefer to have two channels of good content instead of a single channel, and I'll bet that most consumers would agree with me. There's a reason why they advertise quantity instead of quality -- it's what people actually care about.
Of course, there's a point where most people DO care about quality -- stuffing 15 sub-channels into a 19 Mbps broadcast channel is going to piss people off -- but you probably aren't going to hit that point with just 2-3 channels.
A related example: I have a friend that bought a HUGE 1080p HDTV. He loved to talk about how great things looked on it. He bragged one day about how great a certain nature show looked on his TV -- until I pointed out to him that it was a 4:3 show that the TV was stretching to 16:9. He never would have known if I hadn't told him.
He fails to mention battery packs for RAID cards. They maintain power to the disk cache memory on the card in the event of a power failure, which allows the card to finish writing the cache to disk once main power is up again. That's one of the arguments for a hardware RAID solution.
Yes, SSL is about encryption. That's why the signing issue is important -- without it, you are vulnerable to man-in-the-middle attacks, which effectively negates the encryption.
Utah has a municipal fiber network called Utopia.
Not so -- there is quite a bit of photographic evidence that shows a lack of signage. Is it conclusive? No, but it's enough to make assumptions on a Slashdot comment board.
I don't think you should be assuming that.
I couldn't help but laugh a bit at his solution. He talks about "flow management" being put into the core of the network to solve TCP's unfairness problem, but at the end of the article he says:
So, in other words, his solution to the "P2P problem" is just a fancy version of a token bucket.
Don't mistake revenue for profit. If 5% of your users drop your service, you'll lose a small portion of your revenue but perhaps post a larger profit if you can then also cut your bandwidth costs in half.
Of course, but you're ignoring the typical usage pricing model: the regular price covers a large "base" amount of data transfer. This is essentially a hybrid model, where you only pay per megabyte when you use an extremely unusual amount of bandwidth. For example, my ISP does exactly this: I get 100 GB per month that I can use, and overages cost me extra. I am not a typical user -- I occasionally download large ISO's, for example, and I don't use P2P software -- but I have never been hit with an overage charge. I've gotten to the point where I don't even check my ISP's usage report; I'm very confident that I won't hit the 100 GB mark any time soon. Thus, my surfing and downloading habits haven't changed a bit.
Yes, bandwidth pricing isn't a big secret if you're talking about a small or mid-sized ISP. What about Level 3 or Comcast, though? These are the kinds of companies that are actually laying new fiber, both locally and nationally, and the cost of the resulting bandwidth isn't always simple to figure out. In addition, peering relationships between the national ISP's can be a delicate thing (depending on the ISP's involved), and a huge P2P user base on a certain ISP may force them to actually pay for some of that peering instead of getting it for "free". Those ISP's with national backbones have a much more complex bandwidth picture than Joe's ISP Shack that's run out of a basement somewhere.
This doesn't even touch on what seems to be the cable companies' real problem, though: the fact that you share your connection with a few hundred other people in your neighborhood. This means that high usage in a neighborhood can make the connection seem slow even if there is plenty of bandwidth past the cable head end, which necessitates expanding the infrastructure in the local neighborhoods.
Do you have any research (i.e. real numbers) that would support this claim? I doubt it, since in order to know this, you would need to know how much the ISP pays for bandwidth, which tends to be a complex and closely guarded secret.
It's much more complicated than that. The P4P paper highlighted that the fundamental issue for the ISP is not distance or latency -- it's just about costs. So, in the BT case they pointed out, the best peers from a user's latency situation are not necessarily the best ones from an ISP's cost situation, and vice versa. If a P2P client wants to help their ISP reduce costs (and thus neuter the ISP's fundamental P2P objections), they simply need more information from the ISP about which network paths are more preferred than others. I'm not convinced that the P4P proposal is the best way to do that, but it's an interesting idea.
Yeah, I guess they could do that, though I don't think it would be effective: a P2P client actively tries to saturate its download capability, and most consumer connections have a much higher download speed than upload speed. Thus, you would probably only "catch" a small number of P2P users, it would have a high false positive rate, and it introduces quite a bit of new billing complexity.
I much prefer the simple approach: bill by excessive usage. So long as the ISP is perfectly clear what the caps are, what the penalties are, and provide a way for the users to check their usage, I'm fine with it. Of course, there is another huge flaw -- a typical lack of competition in the "last-mile" market -- but that's another discussion.
Okay, here it is: P4P: Explicit Communications for Cooperative Control Between P2P and Network Providers. The relevant information is under section 4. Here's the excerpt:
This actually isn't always a great solution, from a cost perspective. Slashdot recently had an article that talked about P4P, which allowed ISP's to give P2P clients bandwidth policy hints -- the article pointed out that it can sometimes cost an ISP much, much more to transfer data between customers than out to the general internet. It specifically mentioned ISP's that ran on top of BT's infrastructure, but I imagine it would be similar for some DSL providers in the US.
Are you saying that your ISP isn't living up to its contract with you? You don't need anything fancy to fix that -- just file a lawsuit. If they truly promised you unlimited bandwidth (as you interpret it), then you should easily win.
On the other hand, you might not completely understand your contract, and thus would take a serious beating in court. Either way, you need to accept the harsh reality that any ISP that offers broadband service (1+ Mbps) without transfer caps will go out of business within 2 years.