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

[Jon Grimm <jgrimm2@us.ibm.com>]

"David S. Miller" wrote:
> 
>    From: Sridhar Samudrala <sri@us.ibm.com>
>    Date: Wed, 8 Jan 2003 15:04:53 -0800 (PST)
> 
>    1. Add a new argument to ip_queue_xmit() to pass the value of DF bit.
>    2. Use the __unused field in skb to pass the value of DF bit.
>    3. Let SCTP call its own routine that fills in the ip header with the
>       appropriate value in the DF bit, but this duplicates most of the code
>       in ip_queue_xmit(). Also ip_options_build() needs to be exported.
> 
>    Which option do you prefer? Or can you suggest any better alternative?
> 
> Too bad there's not a 4th option, fix SCTP.  This is really broken
> that the data stream can get into a state where resegmentation cannot
> be performed.
> 
> Sigh... I guess the new argument to ip_queue_xmit() is the least
> intrusive.

I hate to mention it, but there is at least one other alternative (to
complete the picture) that is to chunk up the messages into their
smallest fragment and then bundle these chunks up to the MTU allowable
packet.  
This however does each up space in the packet for each chunk header and
require more processing at the other end to reassemble the records.  

IIRC, this is what OpenSS7s SCTP does, while the KAME SCTP manually
controls the DF bit as per Sridhar's suggestion.   There are tradeoffs
in either approach.

Best Regards,
Jon