Subject: (IPng 6471) Re: Host Fragmentation

From: [email-masked]
Date: Tue, 15 Sep 1998 13:21:45 EDT

In a message dated 9/15/98 11:47:03 AM Eastern Daylight Time, [email-masked]
writes:

> > From: [email-masked]
>  > Date: Mon, 14 Sep 1998 22:08:05 EDT
>  > Subject: Re: (IPng 6448) Re: Host Fragmentation
>  > ...
>  > Here are the most important data of the announcement.

>  >   Microsoft officials said they achieved 920Mbps throughput on a server
>  >   using the AceNIC 180, a Gigabit Ethernet network interface card from
>  >   Alteon, which also supplied the proprietary jumbo-frame technology.
  
>  Ok, does anyone know how big were these jumbo-frames were?  4K?

>  > ...
>  >   The tests were conducted using a single-processor Intel 400-MHz
>  >   Xeon-based server and four 333-MHz Pentium II clients. An Alteon
>  >   Gigabit Ethernet server switch connected the servers and clients.
  
>  This says to me that the jumbo-frames were going from the server to the
>  clients without fragmentation.  That's great.

Not true.  The following paragraph has been left out.

  The tests were conducted using a single-processor Intel 400-MHz
  Xeon-based server and four 333-MHz Pentium II clients. An Alteon
  Gigabit Ethernet server switch connected the servers and clients.

The Alteon Gigabit Ethernet server switch is a fragmenting
gigabit/10/100Mbps switch or extruder, but it could
just as well have been a fragmenting gigabit 10/100Mbps
router.  The point is that server performance goes
up if the server does not do the fragmentation but
instead the fragmentation is off-loaded to an intermediate
packet switch.

>  Yes, you can get better performance with bigger packets.  I don't think
>  anyone argues with that, and this test supports it.  I've shown the same
>  thing many times over the years when I worked at Cray Research.

The only way to use jumbo packets in this situation is to split
them up at the intermediate system.
  
>  Now, as for the "IPv6 won't let me fragment" complaint, I'll offer an
>  alternative view (that I don't necessarily agree with...).  Since the
>  high-speed fragmenting router sits close to the server, draw a circle
>  around both of them and call that your "host".  Then, rather than doing
>  IP level fragmentation, do TCP level splitting of the packet.  It's easy
>  to take one large TCP packet and split it down into multiple TCP packets.
>  The hard part is that you'd have to recalculate the TCP checksum over
>  each piece.

It is certainly an interesting thought.  The procedure would also
have to be applied to UDP and whatever other protocols run
on top of IP, for which TCP style segmentation might
not make sense (I could certainly envisage for some
applications sending video frames in giant UDP
packets, that were never acknowledged and that
could not be reasonably segmented).  I think the main 
drawbacks would be 

1) the greater level of processing power 

a) which might be required at the intermediate system 
to process a given amount of traffic and 

b) which could translate into greater cost or decrease 
the amount of packets that could be processed per second or 

2) inapplicability to the customer application.
 
TCP  segmentation might be an interesting feature to
add to an intermediate system, but it has some
basic limitations.  And the possibility that intermediate
system TCP segmentation might provide a possibly
more expensive alternative to intermediate system
fragmentation hardly provides a justification for
a standards body arbitrarily to forbid network
fragmentation of IP packets when that body
permits host fragmentation of the IP packet

1) which the receiving station could not possibly
distinguish from forbidden network fragmentation and

2) which suffers from precisely the same problems
from which network fragmentation suffers.

>  I'm not really interested in discussing this alternate solution, because
>  I don't especially like it myself; it's too easy to argue about what is
>  wrong with it.  I'm just presenting it as a different way of looking at
>  the issue.  It is actually better than the IP level fragmentation
>  arguement, because 1) lost segments don't invalidate the whole original
>  packet and 2) the client doesn't have the added latency of waiting for
>  all the IP fragments to show up before passing anything up the stack to
>  TCP.

1) is a reasonable point.  2) is only a concern in a lossy environment
which is bad for TCP based applications because even if TCP provides
selective acknowledgement and out of order segment processing,
most TCP applications seem to require sequential byte streams
and could not do much with the processed data until the missing
segments turn up.

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: James Carlson <[email-masked]>
Date: 15 Sep 1998 14:45:28 -0400

> instead the fragmentation is off-loaded to an intermediate

Read the damned datasheet, please.  The Alteon Gb Ethernet switch
supports jumbograms on BOTH the Gb Ethernet ports AND the 100Mb ports.
Without question, that's what this test was using.  That's why they
mentioned the types of cards in the clients.

	http://www.alteon.com/pdf/ace110.pdf?124,174

That I'm even replying shows how much the tie I'm wearing today has
severely constricted the blood flow above the neck.

*Plonk*  Must remember to add this thread to the kill file.

-- 
James Carlson, Consulting S/W Engineer  <[email-masked]>
IronBridge Networks / 55 Hayden Avenue  71.246W    Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA          42.423N    Fax:  +1 781 372 8190
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp
--------------------------------------------------------------------
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]
--------------------------------------------------------------------