If you read the article, it sounds like BitTorrent Inc. is trying to build a mostly-unrelated business (media-on-demand, similar to the iTunes music/TV store) that happens to use the BitTorrent technology and brand.
SeaStar and InfiniPath (and don't forget the XD1) are great for building non-cache-coherent clusters, but those are mostly useful for running specially-written scientific applications.
Horus is used for building Opteron ccNUMA machines with one OS instance that can run any Linux or Windows apps. It's a very different solution for a different market.
ICANN controls IANA, IANA controls IP addresses, get the picture? ICANN has not yet exerted much control over IP addresses because there's no money there for people to fight over. But one day there will be.
It doesn't matter what power the Department of Commerce exercises over ICANN. Neither body exercises any control over the root server operators.
Of course, this can be fixed. ICANN could convince the root server operators to sign contracts forcing them to do what ICANN says. Then the USA or UN takes over ICANN.
Every time GNOME or KDE or some distro vendor decides to change their theme, TigerT, JimMac, and Steven Garrity have to redesign all the icons. I predict that soon after the Tango project is finished someone will decide that "it looks too XP/Aqua-like" or "my distro looks just like all the others" and the designers will be back at work.
It is very disappointing that you can't use IP multicast now in normal applications running over the public Internet.
Indeed.
Why is it that you can't do all this today?
Every multicast group creates a routing table entry in every router that it passes through. If anyone could create multicast groups, backbone routers would have to handle millions of new routing table entries, and that RAM isn't free.
And will IPv6 fix all this with its required multicast support?
IPv6 cannot require anything, because the IETF has no way to enforce such requirements. So multicast and IPSec may be "mandatory to implement", but nobody can force anybody to turn them on.
Your understanding is way off. Digital TV is always transmitted compressed to 8 Mbits/s or less. And the fastest FTTH available in the US is 30 Mbits/s. But the channel-change latency is caused by IGMP join and P/B-frames, not lack of bandwidth.
No one cares. Other companies (Minerva and Kasenna come to mind) have been selling IPTV products for years. It's a little late for Cisco to put the smack down on an entire industry now.
How much DRM and proprietary hardware will be needed to view it?
The same amount as with digital cable. IPTV looks and feels just like digital cable (the boxes are even made by the same companies); the only difference is RTP/IP vs. TS/QAM transport protocols.
Anything less than one jnd is "instant", and I vaguely remember reading that MS has some trick to do channel changes in only a few RTT, which would be good enough.
(Background: Analog TV systems can usually change channels in a few frames. But digital systems have to wait for the next I-frame, which may be a half-second or more. But if a server sent you the previous I-frame over unicast, you could start decoding much sooner.)
If anyone could push wide deployment of IP Multicast, it would be MSFT.
I doubt it. MS has been pushing IPv6 for years, and where is it?
Then again that would level the IPTV playing field somewhat, which is not the MSFT way.
Exactly. The MS IPTV business model does not involve sending anything over the Internet; all the video stays within each ISP's network. Thus no changes to the Internet backbone are needed.
But will government, cable distributors and Hollywood allow it?
Verizon and SBC have been having some problems licensing TV channels, but they'll probably just spend their way through the problem. There are also local franchise problems that are being slowly solved in various legislatures.
I am very interested in seeing what MS can do to overcome bandwidth concerns at the backbone, ISP and user level
You can't fix this problem in software. SBC is using VDSL over the last mile and the video will all be flowing over their own network (aka "walled garden"). IP multicast cuts down on the backbone traffic a lot.
IPTV could destroy Tivo, Comcast and Fox if the content is broadcast quality or better.
It is broadcast quality, but for the forseeable future you'll only be able to get IPTV from your last-mile broadband provider. Obviously cable companies have no need for IPTV, so that leaves the telcos. Telcos are just starting to roll out broadband networks that have enough capacity for IPTV (VDSL/FTTH). TiVo is an equipment/software provider, so they can survive in an IPTV world by making IPTV boxes instead of cable boxes. Fox is a content company, so IPTV will just be another distribution channel for their content.
ICANN is not a government entity, but all their authority over the DNS root zone comes from a contract with the DoC. The US government can shut down ICANN or veto any ICANN decision if they want to.
Yes, some people have thought about it. DHTs can lead to land grabs (where someone writes a script that claims every name they can generate) and network partitions that cause different clients to see different mappings (like IRC netsplits, but worse).
The most interesting proposed solution IMO is the Levien trust metric (PDF), but it doesn't guarantee consistent mappings if each user acts as their own trust root and it potentially requires users to input trust info.
Slashdot Mirror
If you read the article, it sounds like BitTorrent Inc. is trying to build a mostly-unrelated business (media-on-demand, similar to the iTunes music/TV store) that happens to use the BitTorrent technology and brand.
The company is actually worth much more, considering that $8.75M is the amount that VCs have recently invested.
Maybe you should ask Linus Torvalds and friends; they're the ones who have to worry about it.
It's the same as the regular Opteron (otherwise stuff would break).
No, Horus is developed by Newisys, but the people who initiated it have moved on from Newisys to AMD.
SeaStar and InfiniPath (and don't forget the XD1) are great for building non-cache-coherent clusters, but those are mostly useful for running specially-written scientific applications.
Horus is used for building Opteron ccNUMA machines with one OS instance that can run any Linux or Windows apps. It's a very different solution for a different market.
The problem is that it doesn't work with every browser on every platform, even in cybercafes. SET already failed for similar reasons.
I imagine that those who maintain the root DNS servers are reimbursed in US cash.
Nope. Root server operators are not paid anything. Nor do they have any contract with ICANN. A little scary, huh?
I'll be happy if the issue of IP address allocation is handled by the ITU.
Why? What's wrong with the way IANA handles IP addresses? Has ITU handled the allocation of phone numbers well?
DNS should not be under the control of a central organization.
DNS is fundamentally centralized; what alternate kind of control do you propose?
ICANN controls IANA, IANA controls IP addresses, get the picture? ICANN has not yet exerted much control over IP addresses because there's no money there for people to fight over. But one day there will be.
The video quality is crap. The darknet provides much higher quality versions of TV shows.
Don't forget iMovie; Apple is big on people creating their own video.
Looks like Handbrake just got a lot more popular.
I hope that the billing problem will eventually by "solved" by the rapidly dropping price of backbone transport: just don't bill it.
Multicast jamming has been solved with single-source multicast (SSM).
It doesn't matter what power the Department of Commerce exercises over ICANN. Neither body exercises any control over the root server operators.
Of course, this can be fixed. ICANN could convince the root server operators to sign contracts forcing them to do what ICANN says. Then the USA or UN takes over ICANN.
Every time GNOME or KDE or some distro vendor decides to change their theme, TigerT, JimMac, and Steven Garrity have to redesign all the icons. I predict that soon after the Tango project is finished someone will decide that "it looks too XP/Aqua-like" or "my distro looks just like all the others" and the designers will be back at work.
It is very disappointing that you can't use IP multicast now in normal applications running over the public Internet.
Indeed.
Why is it that you can't do all this today?
Every multicast group creates a routing table entry in every router that it passes through. If anyone could create multicast groups, backbone routers would have to handle millions of new routing table entries, and that RAM isn't free.
And will IPv6 fix all this with its required multicast support?
IPv6 cannot require anything, because the IETF has no way to enforce such requirements. So multicast and IPSec may be "mandatory to implement", but nobody can force anybody to turn them on.
Your understanding is way off. Digital TV is always transmitted compressed to 8 Mbits/s or less. And the fastest FTTH available in the US is 30 Mbits/s. But the channel-change latency is caused by IGMP join and P/B-frames, not lack of bandwidth.
No one cares. Other companies (Minerva and Kasenna come to mind) have been selling IPTV products for years. It's a little late for Cisco to put the smack down on an entire industry now.
How much DRM and proprietary hardware will be needed to view it?
The same amount as with digital cable. IPTV looks and feels just like digital cable (the boxes are even made by the same companies); the only difference is RTP/IP vs. TS/QAM transport protocols.
Anything less than one jnd is "instant", and I vaguely remember reading that MS has some trick to do channel changes in only a few RTT, which would be good enough.
(Background: Analog TV systems can usually change channels in a few frames. But digital systems have to wait for the next I-frame, which may be a half-second or more. But if a server sent you the previous I-frame over unicast, you could start decoding much sooner.)
If anyone could push wide deployment of IP Multicast, it would be MSFT.
I doubt it. MS has been pushing IPv6 for years, and where is it?
Then again that would level the IPTV playing field somewhat, which is not the MSFT way.
Exactly. The MS IPTV business model does not involve sending anything over the Internet; all the video stays within each ISP's network. Thus no changes to the Internet backbone are needed.
But will government, cable distributors and Hollywood allow it?
Verizon and SBC have been having some problems licensing TV channels, but they'll probably just spend their way through the problem. There are also local franchise problems that are being slowly solved in various legislatures.
I am very interested in seeing what MS can do to overcome bandwidth concerns at the backbone, ISP and user level
You can't fix this problem in software. SBC is using VDSL over the last mile and the video will all be flowing over their own network (aka "walled garden"). IP multicast cuts down on the backbone traffic a lot.
IPTV could destroy Tivo, Comcast and Fox if the content is broadcast quality or better.
It is broadcast quality, but for the forseeable future you'll only be able to get IPTV from your last-mile broadband provider. Obviously cable companies have no need for IPTV, so that leaves the telcos. Telcos are just starting to roll out broadband networks that have enough capacity for IPTV (VDSL/FTTH). TiVo is an equipment/software provider, so they can survive in an IPTV world by making IPTV boxes instead of cable boxes. Fox is a content company, so IPTV will just be another distribution channel for their content.
ICANN is not a government entity, but all their authority over the DNS root zone comes from a contract with the DoC. The US government can shut down ICANN or veto any ICANN decision if they want to.
ICANN operates under the oversight of the US Department of Commerce.
Yes, some people have thought about it. DHTs can lead to land grabs (where someone writes a script that claims every name they can generate) and network partitions that cause different clients to see different mappings (like IRC netsplits, but worse).
The most interesting proposed solution IMO is the Levien trust metric (PDF), but it doesn't guarantee consistent mappings if each user acts as their own trust root and it potentially requires users to input trust info.