Subject: (IPng 6535) Re: Host Fragmentation

From: [email-masked] (Peter R. Tattam)
Date: Sun, 27 Sep 1998 11:03:55 +1100

In article <[email-masked]> [email-masked] writes:
>From: [email-masked]
>Date: Sat, 26 Sep 1998 10:36:46 EDT

Sorry to say, I totally disagree with your general comments.  As a TCP stack 
implementor, I find that fragmentation is one of the most irritating aspects 
of the implementation.  The cost of handling fragmentation efficiently is 
quite high, both in terms of implementation cost and also in terms of memory 
allocation.  Many stacks operate at a kernel layer and thus to be reasonable 
and not steal too much of kernel ram space (which often has to be in non 
pageable memory). 

It is also a large risk for denial of service since it is a trivial matter to 
construct packets which will rapidly starve an implementation of all available 
fragmentation buffer space.  To prevent this attack, my technique is 
to run two independent heaps, one for regular packets and one for 
fragmented packets. Still, with a 30 sec timeout for fragmented packets, 
*quite* a lot of damage can be done.  Experience has also shown that most of 
the TCP stack killer attacks centre around poor implementations of 
fragmentation. e.g. the teardrop attacks.

It's about time the computing industry took a good hard look at the attitudes 
that say, "let's just throw more RAM or more CPU or more DISK at the problem 
till it's fixed."  Big is not always beautiful.  I get concerned when I do a 
RAM utilization on a Win95 machine and find sometimes that almost half 
the RAM is allocated to system non-pageable memory.  Also don't forget that 
IP6 is being touted for many low memory devices.  You have to take into 
account the small end of the spectrum too.

Peter

>To: [email-masked]
>Cc: [email-masked], [email-masked], [email-masked],
>Subject: (IPng 6533) Re:  Host Fragmentation

>[email-masked] writes:

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

>>  >And about fragment loss, nobody can expect to get top performance
>>  >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.

>I read the <A HREF="ftp://ftp.isi.edu/in-notes/rfc2001.txt">RFC</A>.  Unlike 
><A HREF="http://members.aol.com/Volsinians/fragcomments.pdf">that ridiculous
>Mogul paper</A>, 
>there is nothing really wrong with it except that the abstract calls
>the *procedures* described a protocol(*).

>Here is a discussion of dropping due to memory starvation.

>   Old TCPs would start a connection with the sender injecting multiple
>   segments into the network, up to the window size advertised by the
>   receiver.  While this is OK when the two hosts are on the same LAN,
>   if there are routers and slower links between the sender and the
>   receiver, problems can arise.  Some intermediate router must queue
>   the packets, and it's possible for that router to run out of space.

>The situation described above was true at the time the research for
><A HREF="http://members.aol.com/Volsinians/fragcomments.pdf">that ridiculous
>Mogul paper</A> 
>was performed, but today memory is far less costly.  With a properly
>engineered communications subnet, temporary demands for bandwidth
>greater than link speed should exceed available queue space only
>extremely rarely. (Frequent sustained demands for bandwidth in excess
>of link speed indicate poor traffic engineering.)

>To wit, I believe that the Alteon switch can provide a half megabyte
>of buffering per port.  The standard Intel architecture
><A HREF="http://members.aol.com/Telford001/#PACKET_SWITCHING">
>Freeware/Shareware VLAN Router</A> 
>can run with an order of a gigabyte of
>memory available for buffering.  The Alpha-based Subscriber VLAN
>Router can run with 20 gigabytes or more of memory available for
>buffering.  The author of the contribution to which I am replying
>must repeat until it is understood:

>        MEMORY FOR PACKET BUFFERING IS PLENTIFUL!

>Worrying about routers that run out of space for received packets in
>internets/intranets that have been properly traffic engineered is
>inappropriate with today's technology.

>Here is the the paragraph that discusses loss of packets.

>   The assumption of the algorithm is that packet loss caused by damage
>   is very small (much less than 1%), therefore the loss of a packet
>   signals congestion somewhere in the network between the source and
>   destination.  There are two indications of packet loss:  a timeout
>   occurring and the receipt of duplicate ACKs.

>Neither the first nor the last sentence is not exactly correct.  

>The first sentence suggests that packet loss results mainly from
>damaged packets or from congestion.  In fact, topological
>instabilities (especially in large-bandwidth backbones constructed
>with Cisco routers -- a very common situation) are probably far more
>frequently the major causes packet loss.

>As for the second case, the overwhelming majority of the cases for
>today's Internet, timeouts simply indicate delay (**) in the arrival
>of the ACK.  Delays in the reception of the ACK occur because it takes
>a finite time for any packet to get from its transmitter to the target
>receiver.

>The following non-exhaustive list describes some of the causes of
>delay.

>1) Buffering due to congestion can cause delay *with no packet loss*.

>2) Use of satellite links can introduce delay *with no packet loss*.

>3) A <A HREF="http://members.aol.com/Telford001/#DEVELOPMENT">sophisticated
>switch router</A> 
>like the VLAN Router can detect
>temporary MAC layer topological instabilities that are often not easily
>detectable by network layer routing and buffer packets *with no packet
>loss* until the instability passes.

>As for duplicate ACKs, these usually indicate delays *with no packet
>loss* as in the following scenario.

>1) A packet is sent from the transmitter,

>2) For some reason the packet is delayed getting to the receiver,

>3) A subsequent packet is sent form the transmitter,

>4) The ack on the first packet times out so that it is resent,

>5) All three packets arrive at the receiver *with no packet loss* in
>the order transmitted.

>6) The receiver may send a duplicate ACK to make sure that both the
>transmitter and receiver are synchronized.

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

>Damaged packets and topological instability aside, the comment is
>certainly not true.

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

>This sort of misunderstanding as well as the misinterpretation of 28K
>modem situation previously discussed are good arguments for keeping 
><A HREF="http://members.aol.com/Telford001/#SERVICES">The Critical Review of
>Internet Technology and Intranet Computing</A> 
>(<A HREF="http://members.aol.com/Telford001/#SERVICES">The C.R.I.T.I.C</A>) 
>handy.

>I also recommend 
>The <A HREF="http://members.aol.com/Telford001/">Freeware/Shareware VLAN
>Router</A> 
>to researchers (on tight budgets) that wish to investigate with more
>verisimilitude the behavior of real internets that use modern
>technology and turnkey packet switches.  (I am making available by
>Monday at the Telford Tools Website a version that simplifies
>installation).  These integrated L2/L3 WAN LAN multiprotocol switch routers 
>do not duplicate flaws of Cisco routers, but a network built
>with these devices is a lot more realistic for simulation than a
>network using Linux (or some other Unix variant) running GATED.

>Joachim Martillo
><A HREF="http://members.aol.com/Telford001/">Telford Tools, Inc.</A>  

>(*)This document specifies an Internet standards track protocol for the
>   Internet community, and requests discussion and suggestions for
>   improvements.  Please refer to the current edition of the "Internet
>   Official Protocol Standards" (STD 1) for the standardization state
>   and status of this protocol.  Distribution of this memo is unlimited.

>(**) Steven's observation with regard to timeouts would be more
>applicable to an Internet using the old broken hardware and software
>described in
><A HREF="http://members.aol.com/Volsinians/fragcomments.pdf">that ridiculous
>Mogul paper</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]
>--------------------------------------------------------------------

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