geoff@eagle_snax.UUCP ( R.H. coast near the top) (09/30/88)
In working on the SLIP driver for SunOS 4.0 (yeah, streams, right...)
I decided to enforce the 1006 byte MTU on input, and found
a buggy SLIP client that would occasionally send slightly overlength
packets. On checking back, I found that the "generic" SLIP
driver cares not a jot or a tittle for such things, and will
cheerfully keep stuffing an infinite amount of unterminated
data into the mbuf chain.
My question is, will enforcing the 1006 byte MTU break anything
out in netland (other than the already-identified buggy client,
now fixed)?
Geoff
--
Geoff Arnold, Sun Microsystems Inc.+------------------------------------------+
PC Distrib. Sys. (home of PC-NFS) |If you do nothing, you will automatically |
UUCP:{hplabs,decwrl...}!sun!garnold|receive our Disclaimer of the Month choice|
ARPA:geoff@sun.com +------------------------------------------+rick@SEISMO.CSS.GOV (Rick Adams) (10/03/88)
Please dont enforce the 1006 byte limit. It is a historical curiousity that is still around because when I wrote the original code, the IP fragmentation code of most systems didnt work worth a damn. So, I made the MTU 1006 so it wouldn't fragment going through an IMP. If I didn't have an IMP, I probably would have made it 1534 (or whatever the ethernet is) --rick
ahill@CC5.BBN.COM ("Alan R. Hill") (10/03/88)
Rick, I'll probably regret this but I have to ask why you have the impression that the IMP will not accept messages exceeding 1006 bytes? The X.25 limit is 1024. The 1822 limit is 8063 bits and the DDN X.25 Standard service limit is 8056 bits or 1007 bytes. Can you shed some light on where the 1006 byte number originated? Thanks, Alan
lougheed@CLASH.CISCO.COM (10/04/88)
Alan - Regarding 1822 numerology: 8063/8 = 1007.875, so 1007 bytes is possible, but 1006 is the largest even byte count. Our experience on the DDN is that most systems use 1006 bytes as the MTU. Attempting to use a larger MTU has given us headaches, especially with some Berkeley-derived systems. Invoking the engineering for interoperability principle, the cisco software will never send a DDN bound datagram greater than 1006 bytes, but will accept larger datagrams. Kirk Lougheed cisco Systems
rick@SEISMO.CSS.GOV (Rick Adams) (10/04/88)
When I was running 4.2bsd (or maybe it was 4.1C?) on a vax connected to an IMP via 1822 (circa 1983, when the code was written), "netstat -i" showed an MTU of 1006 for the IMP interface. I believe it is from the 1007 bytes rounded down to an even number because of something that didn't work right with odd numbered MTUs. As I said, it's an historical relic that there is no good reason for perpetuating. The "correct" MTU should really be something like 1024 data bytes + IP headers + TCP headers. Please keep in mind that SLIP was a hack. There was no real design to it. It was a quick solution to an immediate problem. The framing scheme was chosen to be compatible with 3Com's UNET (anyone still remember that?). The MTU was chosen to avoid fragmenting when passing through IMPS. Any other parameter you might find was chosen in a similar manner. I.e. get it to work fast. ---rick
ron@ron.rutgers.edu (Ron Natalie) (10/11/88)
Many PDP-11 IMP interfaces can transfer odd number of bytes well so the outbound MTU was frequently set to 1006 to avoid this problem. Inbound didn't matter because the imp always spit out a few extra bytes on the end of the message. -Ron