Subject: (IPng 6454) Re: Host Fragmentation

From: [email-masked]
Date: Mon, 14 Sep 1998 14:00:15 EDT

In a message dated 9/10/98 4:15:52 PM Eastern Daylight Time, [email-masked]
writes:

> Joachim,

>  > From: [email-masked]
>  > Date: Thu, 10 Sep 1998 14:39:13 EDT
>  > Subject: (IPng 6429) Re: Host Fragmentation
>  > ...
>  > Thus in the current situation to get the highest performance
>  > network service it makes sense when clients cannot
>  > receive jumbograms (the common situation),

>  > 1) for the server to transmit jumbograms,

>  > 2) to interpose a device capable of rapid fragmentation and

>  > 3) for the client to receive the fragments and reassemble
>  > the IP packet from fragments of its MRU size.
  
>  This ignores several things:
  
>  	1) Having a device that is capable of rapid fragmentation
>  	   doesn't mean that the destination host is capable of
>  	   rapid reassembly.

Not a common problem nowadays as far as I can determine.
  
>  	2) The client has to reassemble those fragments before
>  	   it can pass up any of the data to the next layer,
>  	   introducing latency.

As the reconstruction of the original packet occurs
as the fragments of the original packet are being
received and as the reception is slower than
the reconstruction, with careful coding the introduced
latency is vanishingly small especially when
compared with the latencies introduced by
sending smaller non-fragmented packets
upstack.
  
>  	3) If any of the fragments gets lost, all the fragments
>  	   get tossed and the sender has to resend the jumbogram,
>  	   and if any of the fragments get lost, all the fragments
>  	   get tossed and the sender has to resend...

If fragments are getting lost and there is a lot
of retransmission, the situation can be detected
and upper protocol layers that can undertake
to make sure that fragmentation does not
take place.
  
>  Many years ago when Cray computers first got TCP/IP, it was originally
>  based on the 4.2BSD code, which didn't deal with MAXSEG and remote
>  hosts properly.  The main network attachement to the Cray was via
>  Hyperchannel, with a 16K MTU.  Two machines installed at different
>  locations were trying to transfer data across the Arpanet, and they
>  were sending out 16K TCP packets, which got fragmented down to 1K
>  chunks.  The connection was lossy enough that many times one of the
>  16 fragments would get lost, TCP would time out and retransmit another
>  16K packet, a fragment would get lost, and so on.  You could transfer
>  data nicely between the Cray and another remote machine that was on
>  ethernet, due to the smaller MTU, but not between the Crays.

A better implementation of TCP could have dealt with the problem.
  
>  > ...
>  > >  The only things that this article might suggest to me would be:

>  > >  	- Larger MTUs are better than smaller ones if throughput is
>  > >  	  your goal (certainly not a surprise)

>  > But then one should wonder how to optimize network performance
>  > when the receiver MRU is much lower than the transmitter MTU.
  
>  That all depends on whose performance you are trying to optimize,
>  and what part of the network you are trying to optimize.  I don't
>  believe there is one answer that solves all situations.

Is not the attempt to impose one solution for everything one
of the major problems with IPv6?  The situation of a massive
file server with a jumbogram capable adapter card  and
many non-jumbogram capable clients is exactly a
situation, that the current specification of IPv6 does
not handle well because IPv6 imposes a single
solution (host fragmentation) that simply does not
apply in all cases.  The IPv6 imposition is
particularly silly because there is no way
for the receiving host to distinguish permitted
host fragmentation from forbidden network
fragmentation.

Joachim Martillo
<A HREF="http://members.aol.com/Telford001/">Telford Tools, Inc.</A> 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Kevin M. Lahey" <[email-masked]>
Date: Mon, 14 Sep 1998 11:58:01 -0700

In message <[email-masked]>[email-masked] writes
>apply in all cases.

With a massive file server, I'd like to be able to *write* quickly,
too.  Do you propose to have your router reassemble fragmented packets
as they go by to present the server with large packets as input?
That is no more permissable under IPv4 than it is under IPv6;
will that stop you?

I think, but I'm not sure, that IPv9 and IPv17 are available if you'd
like to define your own standads.  :-)

Kevin
[email-masked]