Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!decwrl!ucbvax!tcp-ip
From: Greenwald@SCRC-STONY-BROOK.ARPA (Michael Greenwald)
Newsgroups: mod.protocols.tcp-ip
Subject: ip fragmentation follies
Message-ID: <851229144542.2.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
Date: Sun, 29-Dec-85 14:45:00 EST
Article-I.D.: SWALLOW.851229144542.2.GREENWALD
Posted: Sun Dec 29 14:45:00 1985
Date-Received: Wed, 8-Jan-86 01:59:23 EST
References: <8512290442.AA12446@uw-beaver.arpa>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 17
Approved: tcp-ip@sri-nic.arpa


Yeah, it's been noticed.  I thought Dave had even commented on it in his
"implementation notes", but I can't find my copies, so I didn't check it
up.  I noticed this in multics (it hadn't actually happened, but if you
remember I was trying to decide when you'd rather have *large* ip
packets, and when you'd rather restrict ip packets to the max network
size.  IP reassembly was cheaper than TCP reassembly. (fewer packet
headers to process.)  I thought the only drawback was that in case of a
lost fragment, you had to retransmit the entire packet, but when I
thought about it, I made the same realization that you did.)  My
(minimal) solution is mentioned below.

My multics code had foo$retransmit_packet, foo$forward_packet, and
foo$send_packet for each datagram protocol named "foo".  (IP, UDP, GGP,
and ICMP, as far as I can remember.)  Not only did it keep the same ID,
but it eliminated a certain category of error checking and checksum
generation, where possible.