On Fri, Jun 24, 2011 at 09:48:51AM -0400, Vladislav Yasevich wrote: > I believe there was work in progress to change how window is computed. The issue with > your current patch is that it is possible to consume all of the receive buffer space while > still having an open receive window. We've seen it in real life which is why the above band-aid > was applied. I don't understand this. The rwnd _announced_ is sk_rcvbuf/2 so we are reserving half of sk_rcvbuf for structures like sk_buff. This means we can use _all_ of rwnd for data. If the peer announces a a_rwnd of 1500 in the last SACK I expect that peer to be able to handle 1500 bytes of data. Regardless of that, why would we reserve a sk_buff for each chunk? We only allocate an skb per packet which can have many chunks attached. To me, this looks like a fix for broken sctp peers. > The correct patch should really something similar to TCP, where receive window is computed as > a percentage of the available receive buffer space at every adjustment. This should also take into > account SWS on the sender side. Can you elaborate this a little more? You want our view of the peer's receive window to be computed as a percentage of the available receive buffer on our side? -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html