RE: Status of Operational issues with Tiny Fragments in IPv6

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Then you probably remember Ethernet "trailers" too; they
were required for certain hardware that could only do DMA
when the data was aligned on a page-sized boundary. But
I digress...

Fred
fred.l.templin@boeing.com 

-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com] 
Sent: Friday, May 26, 2006 10:00 AM
To: Templin, Fred L
Cc: Elwyn Davies; Vishwas Manral; v6ops@ops.ietf.org
Subject: Re: Status of Operational issues with Tiny Fragments in IPv6

yes. And DEQNA was in no sense the only one; Cisco routers to this  
day have a capability in RIP to insert time delays between RIP  
updates due to issues in Netware, in which some PC NICs had trouble  
with back to back packets. As I say, those were different days.

The matter of minimizing the number of packets required to represent  
a transport message, however, remains real. Especially in wireless  
networks, there are a number of issues that result in a per-datagram  
probability of loss that is to some degree independent of datagram  
size. Sending less network layer datagrams per transport message  
improves the probability of delivering the entire transport message.  
That is the bottom line of the inspecific ruminations people  
frequently make about "fragmentation problems" and preferring  
transport-layer fragmentation and reassembly to network-layer  
fragmentation and reassembly. So it seems like carrying that  
recommendation forward has value.

On May 26, 2006, at 9:46 AM, Templin, Fred L wrote:
>> There is a discussion of fragmentation and reassembly in RFC 1812  
>> section 4.2.2.7 that may be useful to reference, or at least learn  
>> lessons from. In part, this results from the behavior of NIC cards  
>> in the late 1980's that couldn't reliably receive datagrams back  
>> to back for very long due to chip or memory issues,
>
> Digital Equipment Corporation had such NIC cards in the late  
> 1980's. The DEQNA card in particular could go into "qe restart"  
> mode when it received back to back fragments that arrived too  
> quickly for its little legs to carry. This was exacerbated by  
> packetization mechanisms such as NFS that sent 8KB frames as chains  
> of back-to-back IPv4 fragments. The follow-on DELQA card, as well  
> as "faster" VAX processors, improved the situation.
>
>> and partly this is is due to brain-dead behaviors in early end- 
>> station OS's.
>
> Having authored some of the network drivers in one of those "brain- 
> dead" OSs, there was really nothing that could be done for the  
> DEQNA case. Ethernet of that day and age was supposed to be 10Mb/ 
> sec, but SUN was one of the first vendors that could actually  
> achieve that rate. Times have certainly changed.
>
> Fred
> fred.l.templin@boeing.com