NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/protocol/tcpip/ibmpc/6234

Text File | 1992-11-11 | 3.7 KB | 81 lines

Newsgroups: comp.protocols.tcp-ip.ibmpc
Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!zaphod.mps.ohio-state.edu!cs.utexas.edu!news.uta.edu!hermes.chpc.utexas.edu!news.utdallas.edu!corpgate!bnrgate!bnr.co.uk!pipex!ibmpcug!impmh!cm
From: [e-mail] (Colin Manning)
Subject: Re: Fragmented IP packets: any PD implementations?
Message-ID: <[e-mail]>
Keywords: IP fragments TCP/IP
Organization: Integrated Micro Products Ltd
References: <[e-mail]> <[e-mail]>
Date: Wed, 11 Nov 1992 12:44:24 GMT
Lines: 69

In <[e-mail]> [e-mail] (Erick Engelke) writes:

>A common misconception is that we will get fragmented packets from
>outside our LAN, such as gateways through slower media.  But it is
>the gateway's responsibility to reassemble the frags before putting
>the data onto the LAN at the other end.  That's why people using
>all these freeware TCPs didn't know they didn't have frag support.

Surely, for a gateway, the following is true:
If the received frags from the input network, when assembled, make a
datagram that is larger than the MTU for the output network, the
gateway will have no choice but to fragment it. Similarly, if the MTU
for the output network is less than the MTU of the input net, it may
have to fragment packets that were received unfragmented (assuming
DF is not set; if it is, the packet will get discarded thus
preventing communication completely).

As far as I recall the IP RFC states that support for fragments is
mandatory and not optional.



>The remaining use of fragments is for UDP based services such as
>NFS/RPC/UDP or possibly SNMP.  I have always been critical of the
>use of fragmented RPC's and wished people would migrate over to TCP
>as they are starting to do now for NFS.

>Here's my frustration, fragments rely on 100% delivery and are
>costly in gateways.  And when you encounter problems on your LAN,
>large UDP packets clog it in a needless and futile manner whereas
>TCP adapts.

That is true, but there are other more fundamental reasons why you
would not want to use a connection oriented protocol like TCP, in
certain applications. UDP and IP are stateless. Although a
fragmented datagram will only get there if all its fragments get
there, whatever is using IP must assume that IP datagram delivery
is unreliable.

Personally, I do not think that a network application should
ever knowingly attempt to send a datagram that is bigger than
the MTU of the local net, since it knows (or should do if its
IP layer is compliant with RFC1122) that fragmentation will occur.
Fragmentation should only occur when a gateway discovers that it
has no choice but to fragment when passing a datagram on to a net
with a smaller MTU. I think that NFS is the obvious culprit here.
Given that the large majority of Sun workstations are connected
via a network with an MTU a lot less than 8k, i.e ethernet, this
is a misuse of fragmentation.

Put another way, in my view the point about fragments is that they
are there to provide a mechanism for networks with naturally small
packet sizes to interwork reasonably well with networks with larger
packet sizes. They were not invented in order for applications to
ship objects unlimited by physical network packet size. That is
a function for higher level protocols.

>>Has anyone implemented IP fragment handling in any of the above mentioned
>>products? My personal favorite is WATTCP, but I would be willing to entertain
>>any PD implementation that handles frags. My only alternative is to roll my
>>own :-(.

I have done it in my own TCP/IP.

--
Colin Manning     [e-mail]      Tel: [phone]

--
Colin Manning     [e-mail]      Tel: [phone]