djb@cbosgd.UUCP (David J. Bryant) (08/29/84)
We have had several meetings with a variety of HP people about this issue
recently. You are quite right - the HP implementation of TCP/IP is different
from the standard TCP/IP, and it's intentional on HP's part. As far as I
understand the situation the differences are that HP's version does not
provide/support the following:
1) Urgent Data
2) Graceful Release
3) Option Fields
4) Segmentation and Reassembly of IP packets.
5) Checksumming. (HP figures that this is done adequately in layer 2,
so they left it out to improve performance)
6) Address-Resolution Protocol. HP uses a custom-designed "probe"
mechanism.
The bottom line is that an HP TCP/IP system can ONLY talk to another HP
TCP/IP product! We found this to be an incredible design decision, and
one that is totally incompatible with our requirements.
Further, HP supports only file transfer and remote file access. Virtual
terminal and IPC applications are planned for the future. Yet another
problem area we're having to work out...
According to HP, they have had "several people" question their lack of
support for standard TCP/IP. They are clearly aware of the problem, and
are considering fixing things up, but we have not had any detailed
committment from them. For some reason they are determined to support
their "version" of TCP/IP, but they are talking about some mechanism
that will make it possible to talk both their version and the standard
version with the same software. Regardless, I expect that things will
get fixed eventually - the HP folks have been amazingly receptive to
our requests so far - but it will take time.
Still, we see this as a silly situation, and have yet to understand HP's
reasoning on this one. I'd like to personally encourage every HP owner/user
(and anyone else that can get HP's ear) to strongly "suggest" to their HP
contact that HP get their TCP/IP version in line with the standard, for
innumerable obvious reasons.
As our discussions with HP progress and new things happen, I'll keep you
posted.
David Bryant AT&T Bell Laboratories Columbus, OH (614) 860-4516
(cbosgd!djb)cak@CS-Arthur (Christopher A Kent) (08/31/84)
In my opinion, there are only two words to describe what HP has done with
their "TCP" ...
!!
BBBBBBB !!
BB BB !!
BB BB !!
BB BB !!
BBBBBBB ooooo gggggg uu uu ssssss !!
BB BB oo oo gg gg uu uu ss !!
BB BB oo oo gg gg uu uu sssss !!
BB BB oo oo gg gg uu uu ss
BB BB oo oo gg gg uu uu ss ss
BBBBBBB ooooo gggggg uuuuuuu sssss !!
gg
gg
gg gg
gggggg
and
!!
LL !!
LL !!
LL ii !!
LL nn !!
LL ooooo ssssss iii nnnnnn gggggg !!
LL oo oo ss ii nn nn gg gg !!
LL oo oo sssss ii nn nn gg gg !!
LL oo oo ss ii nn nn gg gg
LL oo oo ss ss ii nn nn gg gg
LLLLLLLL ooooo sssss iiii nn nn gggggg !!
gg
gg
gg gg
gggggg
I can only hope that someone from HP is reading this. Their decision
in this regard is just plain wrong.
chrisreid@Cascade.ARPA (09/05/84)
> Christopher Kent at Purdue should be congratulated on his success in causing > hundreds of sites around the world to pay to ship 2998 characters to convey > three sentences of his *esteemed* opinion. Ah, but Kent is right, and there is so little truth on this network. 2998 characters can be shipped for a few pennies; where else can you get a bargain like that? HP's so-called TCP implementation should be stamped out immediately before people start to use it. Brian Reid Stanford
mark@cbosgd.UUCP (09/06/84)
Now wait a minute. In my discussions with HP (I'm in the same department as David Bryant) I don't recall HP advertising their networking as either a product that can be bought today or as TCP/IP. What they did say repeatedly was that they were watching to see what the rest of the industry does about networking UNIX, and that they will conform to whatever evolves as an industry standard (and their customers request.) Their current in-house implementation is indeed similar to TCP/IP, but isn't in a product. (Unless it's recently become a product and I just haven't heard about it.) In any case, HP is responsive to its customers requests, but they have a big overhead with any product that requires people to do work (being another big memo-producing organization, I feel for them) so there will have to be a big payoff to be worth their while. So I echo David's request that you tell your local HP sales person that their code MUST CONFORM to the industry standards, or it won't do you any good. Point out that you need Ethernet ARP IP TCP Telnet/FTP/SMTP and that it would be nice to have optional enhancements (that can be turned off!) like no TCP checksums, trailer protocols, and Berkeley's rlogin/rcp/rsh/rwho/ruptime. Also, would someone at HP LABS in California please contact whoever is doing their network UNIX development and set up a connection? The best way for them to write compatible code is to plug into an existing network, such as you already have. If you can't afford a leased line or don't want to wait 6 months to have it installed, you can run SLIP over a 1200 baud dialup; we do here and it's fine for testing and even FTP and mail and rsh (but not for remote login.) Mark Horton
jbn@wdl1.UUCP (jbn ) (09/08/84)
#R:cbosgd:-26000:wdl1:8900005:000:881
wdl1!jbn Sep 7 13:51:00 1984
For the information of those trying to get HP to comply with existing
IP/TCP standards, the official standards are MIL-STD-1777 (IP) and MIL-STD-
1778 (TCP). The latter is presently being revised by the Defense
Communications Agency. The person with overall responsibility for this area
is Mike Corrigan, of the Defense Data Network Program Management Office,
in Reston, Virginia, (Corrigan@DDN), 703-285-5030, and DoD activities
interested in IP/TCP can contact him for standards information.
We have an ongoing interest in bringing IP/TCP technology up to the
``plug it in and turn it on'' point, and encourage efforts in that direction.
We did not, in fact, consider HP workstations seriously when we recently
decided to purchase a number of workstatins because HP did not support a
standard network.
John Nagle
Ford Aerospace and Communications Corp.