Re: SCTP path mtu support needs some ip layer support.

[Nivedita Singhvi <niv@us.ibm.com>]

> > fragmentation to retransmit any data bits. If SCTP is not ablet to do this,
> > then you should not support pmtu discovery at all like most of people make
> > for UDP or to follow UDP pattern, fragmenting frames when their size exceeds
> > mtu. It is not necessary to cripple ip_queue_xmit calling conventions
> > to make this, just add a flag to socket to clear DF on oversized
> > frames.
> 
> Some recent incidents have shown that ip fragmentation/defragmention
> at gigabit speed is rather worthless. The reason is that it has no PAWS
> and the 16bit ipid can wrap many times in the standard reassembly
> timeout, leading to lots of misassembled packets on a busy network.
> Mostly that can be catched by computing the transport layer
> checksum, but often enough a misassembled packet can slip through.
> While in SCTP it may work a bit better because it supports stronger
> checksums (but only optionally afaik) it is still too dangerous.
> So in short clearing DF is near always a bug these days.
> 
> -Andi

I'd second that and say that its absolutely a must that SCTP support
path MTU as much as possible, and limit the fragmenting to the unresegmentable
queued stuff only, which should only happen if the MTU changes,
rare enough that it wont be a big deal, and with limited number of
segments affected..

thanks,
Nivedita