Subject: (IPng 6486) Re: Host Fragmentation

From: [email-masked] (Wayne Hathaway)
Date: Wed, 16 Sep 1998 17:30:12 -0700

Richard Draves <[email-masked]> writes:
> I hate to inject reality into this entertaining discussion, but
> I asked someone who was involved with this test, and in fact
> the jumbo-frames were used end-to-end between the client and
> the server. The switch was not doing any fragmentation.

This is indeed true.  But for the point being argued in this
discussion, is it relevant?

Nobody disputes that network devices should be able to fragment
at full speed, nor do they dispute that given a large number of
clients, each should be able to reassemble fast enough.

So apart from the fragment loss question, the server could have
been pumping its data into a giant bit bucket: the performance
improvement came SOLELY from using jumbo frames on the server.

And about fragment loss, nobody can expect to get top performance
over a lossy net, and a decent TCP implementation could adapt to
lossage with an end result that is guaranteed to be no worse than
what IPv6 limits you to, and may well be substantially better.

Again I repeat: Is it reasonable for a protocol of the future to
outlaw the use of network fragmentation simply because there are
situations in which it might be bad with current router or host
stack implementations?

    Wayne Hathaway              Internet: [email-masked]
    Chief Architect                Phone: 408-360-5503
    Alteon Networks                  FAX: 408-360-5501
    6351 San Ignacio Avenue
    San Jose, CA  95119
--------------------------------------------------------------------
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: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 17 Sep 1998 10:08:46 +0200

At 17:30 16.09.98 -0700, Wayne Hathaway wrote:

>over a lossy net

PLEEEEEEEEEEEEEASE: Back to basics:

1) All IP networks have TCP traffic.
2) TCP's rate adjustment is based on losing packets. See RFC 2001.
3) Therefore, ALL networks with TCP traffic on them lose packets.

Repeat until understood:

ALL IP NETWORKS LOSE PACKETS.

How many packets they lose depends on the traffic load and the number
of TCP connections, and the presence of non-adaptive traffic.
But the ONLY IP network that doesn't lose packets is one where the
packet senders are not able to utilize the bandwidth.

I know that, you know that, we all know that.
The question is NOT whether or not we'll lose parts of fragmented
IP packets. It is HOW MANY.

                        Harald T. Alvestrand

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: James Carlson <[email-masked]>
Date: 17 Sep 1998 07:49:58 -0400

> situations in which it might be bad with current router or host

For what it's worth, I actually agree that it's a bad idea to
completely outlaw network layer fragmentation in all cases.  It should
certainly be avoided, optimized around, and generally spat upon, but
not criminalized.

However, framing the argument (pun not intended) in terms of server
performance in some fundamentally flawed test isn't useful.  Talk to
me about multipath problems in heterogeneous networks, and I'm with
you.  Talk about WindozeNT running a web server, and the argument hits
/dev/null along with the other messages in this thread.

-- 
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]
--------------------------------------------------------------------