This writeup is based on my observations at the demo as well as a phone conversation I had on May 12 with Milo Medin, @Home's Vice President-Networks. I've known Milo since his days as NASA's network administrator. He and several other key technical people in @Home have considerable experience in the Internet community; they're long-time participants in the IETF, for example. I don't know of anyone within Time Warner/Road Runner of comparable technical stature. I think this helps explain many of Road Runner's difficulties.
I emphasize that both @Home and Road Runner use different technologies in the different cities in which they operate, so my discussion here is valid only for the San Diego incarnations of these two systems.
Each @Home modem currently supports only a single computer. @Home is looking into supporting additional computers; no additional information was publicly available.
Both Road Runner and @Home use DHCP to assign IP addresses to users. Road Runner issues leases with a duration of 3600 sec (1 hr). Assigned addresses are wholly temporary; the RR system does not make any attempt to assign any particular IP address (or domain name) to any particular user (though an address, once allocated, will not change if the user leaves his computer on continuously.)
According to Milo Medin, @Home's DHCP server issues leases of much longer duration, e.g., 1 week. Additionally, the @Home DHCP server is keyed to a client ID field in the DHCP request; in Windows 95, this is derived from the host name entered in the network setup. The intent is to always give you the same IP address even if your machine has been off for an extended period.
@Home does reserve the right to change individual IP addresses when necessary (e.g., when the address space allocated to a particular cable router nears exhaustion and they have to shuffle address blocks around to free up address space). If it does become necessary to change a user's IP address, they will update the DNS so that the users' corresponding domain name does not change. This is good news for those running servers at home whose domain names are widely published.
Ping tests on Road Runner to the local router typically show a wide variance in round trip delay, from less than ten milliseconds up to nearly two seconds, with an average of a few hundred milliseconds.
Ping tests on the @Home demo network with the upgraded cable router firmware showed consistently lower delays in the range 10 to 30 milliseconds, except for the first packet. The Motorola modems are known to use an adaptive polling scheme where active users are polled continuously while inactive users are polled relatively infrequently. This explains the increased latency for the first packet.
Hopefully, once Road Runner finishes upgrading its cable routers their modems will perform as well as those on @Home.
The @Home advertising copy at the demo claimed that three megabyte files could be transferred in 7 seconds, which is 428 kilobytes/s. Their web page claims 2 megabytes in less than two seconds, which is more than 1 megabyte/sec. This latter figure is apparently derived from the speed of a 10 megabite/sec Ethernet.
These claims are somewhat exaggerated. A file transfer from Qualcomm's public FTP server over @Home went at about 85 kilobytes/sec, about the same as Road Runner on a good day. Of course, throughput depends on many factors, only some of which are under the control of the cable company.
According to Milo Medin, the customized version of Netscape bundled with the @Home service increases the default Windows 95 TCP receive window size to 48K to improve performance. I didn't have a chance to verify the actual value during the demo.
The access link between the San Diego Road Runner head end and the MCI POP in Los Angeles is currently 4 T-1 lines. The access link from the San Diego @Home head end and the @Home backbone is currently a DS3 (28 T-1s, seven times as much as Road Runner).
Both MCI and @Home are Tier 1 backbone networks. Both peer with each other and with CERFnet at MAE-West. This means traffic from @Home customers to CERFnet sites like Qualcomm and UCSD must travel up to the San Francisco Bay area and back -- just as with Road Runner. Neither service has a direct local connection to CERFnet yet.
No packets were lost in a ping test of a few hundred packets from @Home to Qualcomm. Neither were any packets lost in a simultaneous test from Road Runner to Qualcomm -- but then again, it was saturday afternoon, not a workday afternoon when the Internet is usually at maximum load.
There's an interesting oddity in the routing between @Home and Road Runner. Packets from @Home to Road Runner travel over @Home's network all the way to MAE-East in Washington DC, where they enter MCI's network and return to the west coast! I believe this particular route was deliberately chosen by @Home some months ago because of MCI's chronically overloaded router at MAE-West. (Milo points out that it may not be a coincidence that Netscape is a major MCI customer.) This was the same problem that caused the high packet loss rate for packets from CERFnet to MCI and Road Runner, as CERFnet has not tried to avoid the overloaded MCI router at MAE-West.
One can still hope that someday within our lifetimes, @Home, Road Runner and CERFnet will all peer locally within San Diego.