gaige@ncsa.uiuc.EDU.UUCP (10/30/87)
We have done some work with vax's here at NCSA and have found a problem with some of the TCP's not handling MSS directives (Maximum segment size). Because of the size of an appletalk packet not allowing much more than 512 bytes per packet, any ethernet-based TCP/IP that sends a >512 byte packet will not get through the Kinetics box. You might want to check with your vax administrator and see if might be your problem and if he/she would be willing to lower the MSS for the Vax to 512. Gaige B. Paulsen National Center for Supercomputing Applications gaige@ncsa.uiuc.edu (217) 244-1957
ralphw@IUS2.CS.CMU.EDU (Ralph Hyre) (11/11/87)
In article <8710301520.AA05064@lurch.ncsa.uiuc.edu> gaige@ncsa.uiuc.EDU writes: > >We have done some work with vax's here at NCSA and have found a problem >with some of the TCP's not handling MSS directives (Maximum segment size). >Because of the size of an appletalk packet not allowing much more than 512 >bytes per packet, any ethernet-based TCP/IP that sends a >512 byte packet >will not get through the Kinetics box. You might want to check with your >vax administrator and see if might be your problem and if he/she would be >willing to lower the MSS for the Vax to 512. I thought this was what fragmentation was developed for. Can't the Kinetics box handle it? I believe that the default MTU for the Internet is 576 (octets) bytes, so it seems like lots of Kboxes will have this problem. If the K-box can't handle 576 byte packets or do fragmentation and reassembly, then it violates RFC-1009, which specifes IP gateway behavior. Or is it the Mac TCP/IP implementations that can't do reassembly? -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
tom@CITI.UMICH.EDU.UUCP (11/12/87)
>If the K-box can't handle 576 byte packets or do fragmentation and reassembly, >then it violates RFC-1009, which specifes IP gateway behavior. >Or is it the Mac TCP/IP implementations that can't do reassembly? CITI played with putting IP fragmentation into Stanford's KIP code but found out that the Kineticts gateway was unable to receive more that two (if even that) back to back packets from a sun so we droped the work. (If fragmentation ever looks feasable we will give it another try.) Because the Kinetics box can't fragment, our TCP/IP implementation has never had to do reassembly (we do do fragmentation however). We just added Ethernet support to our new version of MacIP and will soon be adding reassembly as well. Tom Unger tom@citi.umich.edu Center for Information and Technology Integration The University of Michigan
ddp+@ANDREW.CMU.EDU.UUCP (11/12/87)
What does not being able to receive back-to-back packets have to do with not doing fragmentation? If the gateway receives a single > 512 bytes packet it should fragment it! Of course if the gateway is going to fragment then the MAC will have to reassemble. PC/IP's have gotten away without reassembly for quite some time, but only because they could receive 576 byte IP packets. Of course if there is a fragmentation happy gateway in the middle (like Bridge's) then they lose... >If the K-box can't handle 576 byte packets or do fragmentation and reassembly, >then it violates RFC-1009, which specifes IP gateway behavior. Be serious. The Kinetcis box misses being RFC-1009 compatible in atleast 100 other ways. What's one more? Drew
cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (11/13/87)
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
ddp+@ANDREW.CMU.EDU.UUCP (11/13/87)
Well, I guess I spoke to soon. I thought someone had said that the MTU was 512 bytes. If it really is 586 then I agree, there is no need to fragment. Drew
cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (11/13/87)
By the way, I should have said level-3 to level-3 not level-2 to level-2 (e.g. network level not data link level). Charlie C. Kim User Services Columbia University
coleman@sask.UUCP (Geoff Coleman @ College of Engineering) (11/16/87)
I guess Larry has been too busy to post the solution.
The problem wqas with the Ultrix end and was due to TRAILERS
being on by default. This messed up PC/IP as well as the kinetics stuff.
As well it affected the terminal emulation by PC-Interface to
an Ultrix box.
Trailers was off on all our UNIX boxes but on by default on the
Ultrix box.
Geoff Coleman | BITNET: Coleman@sask
College of Engineering | UUCP: {utcsri,ihnp4}!sask!skul!geoff
University of Saskatchewan | Compserve: 76515,1513 just a number
Saskatoon, Saskatchewan | voice: (306) 966-5415
"Why does a hearse horse snicker, hauling a lawyer away?"
- Carl Sandburg