Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*SCTP\s+path\s+mtu\s+support\s+needs\s+some\s+ip\s+layer\s+support\.\s*$/: 42 ]

Total 42 documents matching your query.

1. SCTP path mtu support needs some ip layer support. (score: 1)
Author: hert@xxxxxxxxx>
Date: Wed, 8 Jan 2003 15:04:53 -0800 (PST)
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
/archives/netdev/2003-01/msg00064.html (9,546 bytes)

2. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: sri@xxxxxxxxxx>
Date: Wed, 08 Jan 2003 15:06:38 -0800 (PST)
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
/archives/netdev/2003-01/msg00065.html (9,612 bytes)

3. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: vem@xxxxxxxxxx>
Date: Wed, 08 Jan 2003 16:48:43 -0600
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
/archives/netdev/2003-01/msg00066.html (10,442 bytes)

4. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: mm2@xxxxxxxxxx>
Date: Wed, 08 Jan 2003 15:45:16 -0800 (PST)
Then the decision is currently up to you :-)
/archives/netdev/2003-01/msg00067.html (9,640 bytes)

5. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: vem@xxxxxxxxxx>
Date: Wed, 08 Jan 2003 15:56:34 -0800
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
/archives/netdev/2003-01/msg00068.html (10,789 bytes)

6. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: xxxxxxxxxxxxxx>
Date: Mon, 13 Jan 2003 23:48:10 +0300 (MSK)
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
/archives/netdev/2003-01/msg00097.html (10,030 bytes)

7. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: t@xxxxxxxxxxxxx
Date: Mon, 13 Jan 2003 22:07:08 +0100
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
/archives/netdev/2003-01/msg00098.html (10,731 bytes)

8. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: en <ak@xxxxxxx>
Date: Mon, 13 Jan 2003 13:21:59 -0800
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
/archives/netdev/2003-01/msg00099.html (11,327 bytes)

9. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: niv@xxxxxxxxxx>
Date: Tue, 14 Jan 2003 00:25:44 +0300 (MSK)
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
/archives/netdev/2003-01/msg00100.html (9,852 bytes)

10. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: t@xxxxxxxxxxxxx
Date: Mon, 13 Jan 2003 14:54:06 -0800 (PST)
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
/archives/netdev/2003-01/msg00101.html (13,169 bytes)

11. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: sri@xxxxxxxxxx>
Date: Tue, 14 Jan 2003 02:22:12 +0300 (MSK)
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
/archives/netdev/2003-01/msg00102.html (10,849 bytes)

12. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: t@xxxxxxxxxxxxx
Date: Mon, 13 Jan 2003 17:34:12 -0600
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
/archives/netdev/2003-01/msg00103.html (11,795 bytes)

13. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: t@xxxxxxxxxxxxx
Date: Mon, 13 Jan 2003 16:49:33 -0800 (PST)
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
/archives/netdev/2003-01/msg00105.html (13,513 bytes)

14. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: t@xxxxxxxxxxxxx
Date: Mon, 13 Jan 2003 16:56:56 -0800 (PST)
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
/archives/netdev/2003-01/msg00107.html (9,955 bytes)

15. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: xxxxxxxxxxxxxx>
Date: Tue, 14 Jan 2003 04:22:52 +0300 (MSK)
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
/archives/netdev/2003-01/msg00109.html (10,583 bytes)

16. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: xxxxxxxxxxxxxx>
Date: 14 Jan 2003 08:46:04 +0200
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
/archives/netdev/2003-01/msg00119.html (10,211 bytes)

17. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: xxxxxxxxxxxxxx>
Date: Tue, 14 Jan 2003 10:44:54 -0800 (PST)
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.
/archives/netdev/2003-01/msg00121.html (12,308 bytes)

18. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: sri@xxxxxxxxxx>
Date: 14 Jan 2003 22:11:06 +0200
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
/archives/netdev/2003-01/msg00122.html (10,500 bytes)

19. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: berg@xxxxxxxxx>
Date: Wed, 15 Jan 2003 00:16:43 +0300 (MSK)
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
/archives/netdev/2003-01/msg00123.html (10,767 bytes)

20. Re: SCTP path mtu support needs some ip layer support. (score: 1)
Author: t@xxxxxxxxxxxxx
Date: Tue, 14 Jan 2003 14:15:27 -0800 (PST)
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
/archives/netdev/2003-01/msg00124.html (10,699 bytes)


This search system is powered by Namazu