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