Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!CUNIXC.COLUMBIA.EDU!cck
From: cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim)
Newsgroups: comp.protocols.appletalk
Subject: ip fragmentation
Message-ID: <8712181750.AA25185@columbia.edu>
Date: 18 Dec 87 17:51:55 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 39

When does the fact that KIP doesn't handle IP fragmentation hurt?

Steve Fram at CITI suggested trying cross-country (well, not quite
cross-country, but it is pretty far from Ann Arbor to Manhattan) Aufs
sessions.  I found the following.  I:

	o could not speak with their AppleShare server
	o could write files to, but not read files from their Aufs server

The reason was that the KIP boxes do not handle IP fragmentation.  The
MTU between here and CITI is set at 576 (the arpanet default mtu) or
574 somewhere along the line.  The initial startup requires big (602
data bytes) packet to be echoed back and forth.  With their AppleShare
server it was KIP to KIP and things died.  It happened to work with
Aufs because the initial packet is sent by the client to a host that
handles fragmentation.

Writing files to their Aufs server worked because the vax handles IP
frags.  Reading files from their Aufs server fails because the server
uses full size packets and KIP box drops the fragments.

Other random failures would also occur (enumerate, GetIcon, etc. can
all utilize large packets).

Oh well.

The main purpose of this note is to warn people who are running
between gateways that have MTUs less than 603+sizeof(IP)+sizeof(UDP)
that certain session protocols may fail (e.g. ASP).

It is not clear to me that the definition of ASP allows one to by-pass
this problem.

Printing would work fine with MTUs at 576 though since packet sizes
are restricted to 512 bytes.

Charlie C. Kim
User Services
Columbia University