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

["Templin, Fred L" <[e-mail]>]

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.

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.

Fred
[e-mail]