Subject: (IPng 6536) Re: Host Fragmentation

From: Thomas Dineen <[email-masked]>
Date: Sat, 26 Sep 1998 18:29:40 -0700 (PDT)

Peter:

   I totally agree with your article.

   I believe that dropping router fragmentation from IPv6 was a seldom
seen vote for engineering practiallly.
   
Thomas Dineen

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

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