Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!CUNIXC.COLUMBIA.EDU!cck From: cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) Newsgroups: comp.protocols.appletalk Subject: Re: KIP code and Ultrix Message-ID: <8711122100.AA28049@columbia.edu> Date: Thu, 12-Nov-87 16:01:09 EST Article-I.D.: columbia.8711122100.AA28049 Posted: Thu Nov 12 16:01:09 1987 Date-Received: Sun, 15-Nov-87 07:15:56 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 Given that IP packets are simply encapsulated (with no data bytes) in DDP on Appletalk, the MTU (for IP packets) on AppleTalk is 586 bytes (the maximum number of bytes for a DDP packet). (Unless MTU is data bytes in an IP packet and not the entire packet). As I understand it, the original message from Gaige Paulsen was relevant since the Ethernet MTU is 1500 or so. In terms of IP, the original UDP gateway software from Stanford (and the combined gateway software from Kinetics) turn the FastPath into what can be best considered as as "loosely-connected" front end communications (for TCP/IP) processors for the various Macs on the AppleTalk network... Communications between the front end processor and the clients (macs) are not based upon TCP/IP, but a mix of loosely defined mechanisms (c.f. ip.at in the kip distribution). (Technically, I guess you would call it a level-2 to level-2 bridge where the two levels are in different protocol stacks). It's really the same story for the KIP code from Stanford, but it has better functionality. Current versions of FastPath software are limited to receiving 630 bytes (or less in some cases) due to the way buffers are managed - you can get around this limitation, but it's a LOT of work. This leads to the conclusion that making the FastPath fragment IP packets going from the EtherNet to the AppleTalk is a proposal of limited utility. In any event, with above paradigm of the FastPath as a front-end processor, then you can just say that every client is "virtually" hooked to the ethernet with a MTU of 586, so why should the FastPath fragment? Charlie