netdev
[Top] [All Lists]

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

To: Jon Grimm <jgrimm2@xxxxxxxxxx>
Subject: Re: SCTP path mtu support needs some ip layer support.
From: Nivedita Singhvi <niv@xxxxxxxxxx>
Date: Wed, 08 Jan 2003 15:56:34 -0800
Cc: "David S. Miller" <davem@xxxxxxxxxx>, sri@xxxxxxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
References: <Pine.LNX.4.33.0301081451110.2281-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20030108.150638.09647984.davem@xxxxxxxxxx> <3E1CAACB.5D1B82DB@xxxxxxxxxx>
Reply-to: niv@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
Jon Grimm wrote:
> 
> "David S. Miller" wrote:
> >
> >    From: Sridhar Samudrala <sri@xxxxxxxxxx>
> >    Date: Wed, 8 Jan 2003 15:04:53 -0800 (PST)

> > 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.

Jon, from the performance standpoint, that would be the least
preferred approach, right? Also, adding the argument to ip_queue_xmit()
would at least be a general solution for other possible protocols,
raw apps, etc or features that might want to make use of it..
(heaven forbid ;))..

thanks,
Nivedita


<Prev in Thread] Current Thread [Next in Thread>