While working on the SCTP path mtu support, i realized that SCTP needs a mechanism to set/unset IP DF bit on a per-message basis(let ip_queue_xmit() know that it is OK to fragment this particular sk
From: Sridhar Samudrala <sri@xxxxxxxxxx> 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
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 al
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
Beware! To all that I can say, clearing DF on some packets compromises path mtu discovery. If you need to have cleared DF on some packets in a flow, this means in fact, that path mtu discovery is no
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 re
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
Exactly. And it is exactly why I said that this compromises all the pmtu discvoery and why I would like people consulted SCTP designers before doing this step. I cannot believe that new protocol was
I guess SCTP desginers have thought of this and explicitly indicate that we should resort to IP fragmentation when it is detected that an already fragmented message exceeds the PMTU. From Sec 6.9 of
Not to add any arguments just to help a broken protocol. Simply to behave like UDP, i.e. to fragment all the oversized frames. Probably, even new flag is not required, just check for It is almost eq
So in short clearing DF is near always a bug these days. Exactly. And it is exactly why I said that this compromises all the pmtu discvoery and why I would like people consulted SCTP designers befor
Any record based protocol that supports path mtu discovery needs to rely on ip fragmentation when pmtu is lowered and a packet needs to be re-fragmented. In fact, both ipv4 and ipv6 path mtu discover
SCTP does segment the packets based on the current PMTU and sets DF bit to not allowing IP fragmentation. The problem occurs when the PMTU shrinks and there are outstanding segmented packets which ne
I did not disagree with the first one, actually. :-) It was cleaner, to be honest. In any case, after reading mail by Jon Grimm, the things became cleaner. BTW what is "chunk" size in current implem
Setting DF=0 allows intermediate routers to fragment the packets as well. I was proposing that you allow the IP layer to fragment the packets at source host only, and then set DF=1 on the IP fragment
So can i go ahead and add an argument(ipfragok) to ip_queue_xmit()? The maximum chunksize is set to (pmtu - SCTP+IPheadersizes). You seem to be suggesting the use of lowest possible pmtu as the max.
IPv6 is simpler, because the specification asserts that every IPv6 capable link must support a MTU of at least 1280 bytes. If you don't generate packets larger than this you don't have to worry about
Positive. ... Nope. Reread the paragraph and look how UDP in IP_MTUDISC_DO mode works. (The case of IPv6 is especially intersting) Adding similar mode to SCTP is necessary to my opinion. Despite of
Yes. If we restrict the max. data chunksize to 1280 bytes for ipv6 and 576 bytes for ipv4, we could have avoided ip fragmentation alltogether. But this will add unnecessary overhead of sctp fragmenta