Re: [v6ops] new draft: draft-generic-v6ops-tunmtu

[Joe Touch <[e-mail]>]

Hi, Fred,

On 6/25/2012 1:25 PM, Templin, Fred L wrote:
> Hi again Joe,
>
>>>     "Work with slow machines leads us to believe that if it is
>>>      necessary to fragment messages, sending the small IP fragment
>>>      first maximizes the chance of a host with a slow interface of
>>>      receiving all the fragments."
>>>
>>> ??
>>
>> I would expect the excerpt above refers to systems where the need to
>> create a new entry for a new fragment interferes with receive
>> processing, so a small first fragment helps in that case. It does assume
>> that there's no persistent reordering, and assumes a somewhat broken
>> receiver anyway though, IMO.
>
> Actually, I have some real-world experience behind this.
> In 1986, I was asked to look into a problem where a DEC
> VAXStation with a DELQA NIC was performing very poorly as
> an NFS file server. We found that the DELQA actually reset
> itself if it ran out of receive ring buffers, which is
> exactly what was happening when enough fragmented
> IPv4/UDP/NFS packets arrived in bursts. There was literally
> nothing to be done for it - the hardware was deemed broken,
> and the VAXStation/DELQA configuration was disqualified
> as an NFS server platform.

Sure, it's not surprising...

> Right around the same time, a DEC colleague was off writing
> "Fragmentation Considered Harmful", which (IMO) is where the
> whole fragmentation/reassembly/MTU debate went sideways. I
> was never consulted on that writing, but my input would have
> been that the protocol shouldn't be changed to accommodate
> broken hardware. We are still living with the "harmful"
> stigma today, but we need to get beyond that if we're
> going to accommodate tunnels.

Yup - you note too it seems like not being able to setup the fragment 
reception at line rate is an implementation failure, not necessarily 
something we should modify protocols to address.

Joe