Re: Questions from a User Perspective
Frank Kastenholz <kasten@ftp.com> Wed, 09 June 1993 14:24 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04448;
9 Jun 93 10:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04439;
9 Jun 93 10:24 EDT
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13173;
9 Jun 93 10:24 EDT
Received: by thumper.bellcore.com (4.1/4.7)
id <AA11215> for ietf-archive@nri.reston.va.us; Wed, 9 Jun 93 10:23:34 EDT
Received: from ftp.com by thumper.bellcore.com (4.1/4.7)
id <AA11203> for /usr/lib/sendmail -oi -fowner-pip X-pip;
Wed, 9 Jun 93 10:23:25 EDT
Received: by ftp.com
id AA23658; Wed, 9 Jun 93 10:22:00 -0400
Date: Wed, 9 Jun 93 10:22:00 -0400
Message-Id: <9306091422.AA23658@ftp.com>
To: SSmith@chipcom.com
Subject: Re: Questions from a User Perspective
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten@ftp.com>
Reply-To: kasten@ftp.com
Cc: tuba@lanl.gov, pip@thumper.bellcore.com, sip@caldera.usc.edu,
SSmith@chipcom.com
>1. If you were here in Detroit (MAP heartland), with these people deciding >to go full-bore with IP instead, what should be the message a network person >should give them? Just use IP and don't worry about IPng until it's solved; >push for convergence of IP and ISO; push for one of the three approaches >under consideration; something else? Does the use of CLNP by anything other >than addresses (RFC 1454 indicates not, I believe)? >(If not familiar with Manufacturing Automation Protocol, it uses OSI.) For someone installing a network today, they should use IPv4. The reason is simple, there are no IPng products available (sorry tubateers, there are no commercial products that I am aware of that run TCP/UDP/... over CLNP). As to the effort itself. There are obviously the three main camps, PIP, SIP, and TUBA, and their partisans would like you to support their efforts. There are also a number of people who do not believe that any of the three efforts truly address the major problem that we are facing; that routing is not scaling well as the Internet grows. What is the message to give to people? 1. Input from "users" is important to the IETF -- we lack it. 2. If they wish to get involved, they are welcome to do so, but they should study all the issues, both technical and political. > 3. Why are standard protocols not found among "neat" commercial products - in > particluar NOVELL? Do they take short-cuts which can't be done in a Many of these (Novell in particular) were developed out of Xerox's XNS stack. For a while, in the early 80's, XNS was a serious contender for LANs, and stuff developed then was based on XNS (I vaguely recall articles in the popular press proving that TCP/IP could not work on a LAN). Now they have the installed base problem. > "standard"? If so, how come over half the world's business can be done with > a protocol that is "less than standard"? Couldn't standard protocols embrace > the same efficiencies attained by these commercial products? (Question: My > understanding is that internal checksums are often avoided in these > protocols. If so, why can't they just be removed from the "standard"? Could > one specific value of the checksum be used to mean "consider me good", and > permit checksums to be used where desired and set to this constant value when > not?) These "optimizations" all make the assumption that the packets are adequately protected by the datalink checksum (e.g. Ethernet FCS). This is more or less ok when you are dealing with a single datalink (which could be bridged/repeatered) because the datalink FCS is, in effect, an end-to-end checksum on the packet. However, once you get to a routed network, the datalink FCS is no longer end-to-end. In each router, the datalink checksum is checked on reception and a new one generated on transmission (this is needed because the packet changes (TTL gets decremented, maybe the packet gets fragmented), or because you are changing media (going from Ethernet to a WAN)). So, if an "optimized" packet goes through a router, there will be places where the packet is not protected by an end-to-end checksum. So, the TCP/UDP checksum is used to provide end-to-end protection. Once you have an internetwork layer (such as IP), you can not assume that the packets will never go through a router. Finally, checksum calculations do not seem to be as big, bad, and ugly as one would think. For instance, in TCP, the biggest performance hit seems to be poor timeout/retransmission algorithms. > 3a. If the IPng activity can do a really grand job, why would it not be > reasonable for commercial LAN packages to pick it up as the native protocol? > Is this wishful thinking? Those of us working on IP (or IPng) all hope so. > 4. ATM is in every data comm article. Is there anything about this > development which will impact IP's evolution? ATM is the current "hot thing". It receives a lot of press. Some people consider it nothing more than another data link -- which is to say no real impact on IP. Others consider it The One True Networking Solution which will solve all of your problems. Still others think that it is a solution in search of a problem. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000
- Questions from a User Perspective Sam Smith 8005
- Re: Questions from a User Perspective Frank Kastenholz
- Re: Questions from a User Perspective Christian Huitema
- Re: Questions from a User Perspective minshall