| To: | kuznet@xxxxxxxxxxxxx |
|---|---|
| Subject: | Re: SCTP path mtu support needs some ip layer support. |
| From: | Jon Grimm <jgrimm2@xxxxxxxxxx> |
| Date: | Mon, 13 Jan 2003 17:34:12 -0600 |
| Cc: | Andi Kleen <ak@xxxxxxx>, davem@xxxxxxxxxx, sri@xxxxxxxxxx, netdev@xxxxxxxxxxx |
| Organization: | IBM |
| References: | <200301132125.AAA09366@sex.inr.ac.ru> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 |
|
kuznet@xxxxxxxxxxxxx wrote: Hello! It is indeed designed this way. http://www.ietf.org/rfc/rfc2960.txt section 7.3 discusses the differences in SCTP PMTU discovery versus RFC 1191. SCTP packets are filled with "chunks". Data records can be broken into multiple chunks. Chunks are then "bundled" into the packet. Once a TSN (Transmission Sequence Number) is assigned to a data fragment (chunk) of a record, it can not be further fragmented. This should be a rare occurance, but can happen when PMTU shrinks. Now, that being said, there is an alternative that I originally alluded to. That is, pre-fragment chunks down to the smallest possible MTU's needs and then bundle the chunks up together to satisfy the current PMTU. If the current PMTU shrinks, bundle in fewer chunks, down to the smallest packet containing a single chunk. There is a little extra processing at each end and each chunk within the packet eats up a chunk header of 4 bytes.
|
| Previous by Date: | Re: SCTP path mtu support needs some ip layer support., kuznet |
|---|---|
| Next by Date: | Re: snd_cwnd drawn and quartered, kuznet |
| Previous by Thread: | Re: SCTP path mtu support needs some ip layer support., kuznet |
| Next by Thread: | Re: SCTP path mtu support needs some ip layer support., Sridhar Samudrala |
| Indexes: | [Date] [Thread] [Top] [All Lists] |