Subject: (IPng 6515) Re: Host Fragmentation

From: [email-masked]
Date: Thu, 24 Sep 1998 08:55:17 EDT

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

> [email-masked] (Gunnar Lindberg) writes:
>  >     b)	The other fragments may still have been transmitted,
>  > 	using up bandwidth and other (network) resources.
>  > 	Now, that *is* bad.

>  Quite true.  To avoid that, we'd need some kind of horrible ATM-like
>  PPD/EPD trick, which implies per-flow state.

>  This congestion problem with IP fragmentation also gets noticeably
>  worse as the drop rate goes up.  You very quickly into a situation
>  where the only things that are sent are worthless shards of broken
>  packets because IP, unlike TCP, is not congestion-sensitive.  And all
>  of those fragments with offset==0 cause stale reassembly buffers to
>  time out in the affected hosts ...
  
>  (Wonderful congestion-avoidance tricks like RED would seem to make the
>  problem worse still, since they cause statistical rather than bursty
>  packet loss, which is exactly the situation in which IP fragments fail
>  to reassemble at high rates.)

Is there perhaps some data or a paper more reasonable than the
fundamentally vacuous and worthless Mogul fragmentation paper?  I will
read it.  We can hope the argument of such a paper will not depend on
15 year old pronet-10/80 adapters and buggy 4.2 BSD software.

I have the perhaps mistaken impression that ATM systems typically do
not have a lot of queuing built into them and that the designers of
ATM were targeting problems like streaming video.  In situations and
environments that are more amenable to statistically multiplexed
packet switching, sufficient per transmitter per receiver queuing in
the face of transient demands for outgoing bandwidth greater than the
outgoing channel bandwidth eliminates almost all fragment loss.  If
demand on a channel for outgoing bandwidth greater than the channel
bandwidth occurs too frequently for too long, the demand is beginning
to appear sustained.  Either the traffic may not be amenable to
statistically multiplexed packet switching techniques or the traffic
engineering of network is or has become incorrect, in which case a
higher bandwidth link is required.

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 10:03:48 -0400

At 08:55 AM 9/24/98 EDT, [email-masked] wrote:
>ATM were targeting problems like streaming video.  

ATM will and does queue. Whether a given cell is queued or not,
and how much it's queued, depends on the traffic class and parameters
of the cell's VC and the load. For example, CBR traffic tends to be
very sensitive to delay, so will tend to have short queues, while
UBR or ABR is not so sensitive so it can build up queues (of course,
how large the queue gets depends on how much memory is in the
switch).