Subject: (IPng 6514) Re: Host Fragmentation

From: [email-masked]
Date: Thu, 24 Sep 1998 08:28:49 EDT

In a message dated 98-09-24 06:02:45 EDT, [email-masked] writes:

> There is at least one case where fragmentation can cause severe
>  problems (page 4 in "Fragmentation Considered Harmful"). If you
>  fragment and one of the fragments gets dropped:

>      a)	The entire IP-packet is lost.
>  	Maybe no big deal, that's life on the Internet.

>      b)	The other fragments may still have been transmitted,
>  	using up bandwidth and other (network) resources.
>  	Now, that *is* bad.

>  That's reality. If that requires another paradigm is beyond me.

What reality?  If a fragment gets dropped every other packet, there is
a problem.  If a fragment gets dropped once every 10,000,000 packets,
this dropping is more in the range of the bit error rates.  All the
models that Kent and Mogul provide in that paper are worthless because
they are assuming some sort of deterministic fragmentation caused by
pronet 10/80 adapters (how often do we see these around today?), buggy
4.2 BSD implementations of the network layer that are approximately 15
years old (time to upgrade the system) and old pre-1987 memory starved
routers (I think it is time to replace them).

If someones provide some real data on today's network and reasoning
that does not depend on the assumption of old-fashioned, poorly
designed or misdesigned hardware and very old very buggy software,
there would be some reason to pay attention to his analysis.  Paying
attention to the Mogul paper to design the protocol of the future is
ludicrous.  

If fragmentation loss begins to be a problem, there are ways to try to
adapt in software.  Maybe the transmit congestion control mechanisms
can be modified to detect fragment loss.  But not even attempting to
deal with the problem because programmers in 1985-7 were not up to the
job is simply inappropriate.

In any case, IPv6 permits host fragmentation.  I can certainly
think of scenarios where host fragmentation causes problems
that are solved by network fragmentation (not to mention my
web server that gets 30% more performance with network
fragmentation than with segmentation or host fragmentation).
Why permit host fragmentation and forbid network fragmentation?

Suppose near the transmitter there is an underpowered (non-wirespeed
router that can't keep up with data being received) when the packets
are small on a large MTU medium.  Guess what? Small segments 
or fragments from the host (permitted by the IPv6 specification) could 
worsen the problems at the router, while sending large packets with 
downstream network fragmentation beyond the underpowered router 
might make the problem livable.  

So you argue that the congestion control mechanisms would solve the
problem be detecting congestion.  Suppose that the congestion is being
caused by 18,000 upstream source hosts that are already only sending
one segment at a time because they have detected the congestion or
because the connections are all in the initial phases of the congestion
adaption algorithm. Maybe 2,000 hosts have nothing to send.
Maybe 2,000 packets got lost and each of the 2,000 hosts that sent 
the dropped packets throttle their transmit rates.  Suppose while those 
2,000 are throttled, the other 2,000 hosts start sending packets.  
Another, 2000 hosts loose packets while the 2,000 hosts that were 
throttled start transmitting again, and this times the packets
from these hosts get to the destination and get acknowledged quickly
so that they up their rate of segment transmission.  Lots of thrashing 
can occur for a long time.

Suppose that packets 10 times as large were sent 1/10 as frequently.  
Assuming  the hosts are generating data at the same rate in the 
jumbopacket and normal packet scenaries, there will be only about 
200 packets lost per second assuming that the router has the 
same problems in the jumbopacket scenario that it has in the 
small packet scenario.  But guess what? The router is now doing 
1/10 the number of look-ups per second.  It might keep up, and
the network could settle down into a nice steady state with
no packet loss

You argue the condition is unlikely.  Guess what?  There is so much
traffic and so many packets in today's Internet that every scenario
occurs, and the situation described above is probably at least as
likely as finding 1987 or before pronet-10/80 adapters, buggy 4.2 BSD
implementations or at least 11 years old memory starved routers in
use.

So you argue by permitting network fragmentation, I am designing
to the needs of inadequate hardware.  I say.  No, I am making
sure the design is robust in the face of inadequate hardware. 
Mogul and Kent's philosophy is exactly the reverse.  They say
inadequate hardware and software exist;  therefore, performance
on adeqate hardware and software systems should be crippled. 

Does such logic make any sense whatsoever?  Is it good
engineering?

There simply is no reason to forbid network fragmentation while
permitting host fragmentation.  And the Mogul paper is not a
reasonable basis for any 1998 design decisions (in fact any design
decisions for technology to be developed after 1989 and even
1989 is a stretch because the systems that Mogul was using
were probably already out-dated in 1987).

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: Frank Kastenholz <[email-masked]>
Date: Thu, 24 Sep 1998 09:42:05 -0400

>attention to the Mogul paper to design the protocol of the future is

Packet loss in today's network is a not insignificant problem.

About a year ago I was doing some web browsing from home
looking at some pages that had several moderate to large
pictures on them. While I have a 28.8 modem, I was getting
only a couple hundred bytes/second aggregate goodput
downloading the pages, much less than the 2-3KB
I should see (doing simple arithmetic). At first I
thought it was just some odd property of the compression
in the modem. Soon I notived that the aggregate goodput
was much higher for pages with only one or two pictures
than, say, 5 or 6. I turned on a packet tracer, downloaded
a page with several pictures and discovered some truly odd
packet reception patterns. Lots of retransmissions, occasionally
I'd get the same packet (by TCP sequence number) several times
back to back, etc, etc. 

To make a long story short, the problem was that I had multiple
TCP connections open (one per image) and they all were imploding
onto the same dialup server at my ISP. The server's queue was
filling and packets were being discarded left and right. Basically
I was getting randomly selected packets from the stream. The server
TCPs were not behaving well -- either they weren't doing
good congestion avoidance and backoff, or the traffic loss
was so variable that the server TCP just couldn't make sense out
of the acks it was getting from me. (once I saw what was
happening, I reduced the number of simultaneous connections
to 2 and goodput went up to about 2.5KB).

So, if these packets were IP fragments rather than individual
TCP segments, the odds would be good that I would have received
0 complete TCP segments.

You might say "One person, at home, doing web browsing, does
not a network problem make". My response is that there are a
lot of people doing web browsing at home. If this is a common
situation (I suspect it might be, though I have no evidence),
then it does add up to a real network problem.

This all said, I do not believe that an outright ban on 
fragmentation by routers is appropriate. I also believe
that hosts should use path MTU discovery and be
the primary ones responsible for fragmentation,
and routers do it only as a "measure of last resort".
The only way I can think of to enforce this behavior
is to observe that when routers have to fragment packets
their performance drops (it takes more instructions/cycles to
fragment a packet than not to), so the throughput of the
network will drop if/when a host sends packets that need
to be fragmented.

>can be modified to detect fragment loss.

Arguably, this could be done. But it seems to me that having two
layers do congestion control, loss detection, etc, etc, is a bad
architectural choice. Even having IP and TCP both slice up
large blocks of data into smaller blocks (fragmentation and segmentation
respectively) is a bad idea, but because of the dynamic nature
of routing, having IP do it as a measure of last resort is probably
not unreasonable (since the alternative is to drop a packet, possibly
sending a 'too big' message, and causing tcp backoffs when the
backoff isn't necessary).

>are small on a large MTU medium.  

That's sort of like putting a Rolls Royce Merlin engine in a Cessna
172 airframe and then whining that whenever you start the engine, the
torque flips the plane over onto its back.

In other words, if performance is that critical to the application,
you have to engineer the whole system (by system I mean the transmitter,
the routers, the media, the paths, etc, etc) to meet the goals.