Wei Yongjun wrote: > Vlad Yasevich wrote: >> Wei Yongjun wrote: >> >>> The sender should create a SACK only if the size of the final SCTP >>> packet does not exceed the current MTU. Base on RFC 4960: >>> >>> 6.1. Transmission of DATA Chunks >>> >>> Before an endpoint transmits a DATA chunk, if any received DATA >>> chunks have not been acknowledged (e.g., due to delayed ack), the >>> sender should create a SACK and bundle it with the outbound DATA >>> chunk, as long as the size of the final SCTP packet does not exceed >>> the current MTU. >>> >> >> I like this much better, but the one thing I don't like is that we end >> up delaying the SACK if it doesn't fit in the chunk. >> > > Why we need to send the SACK immediate? Just to make the one send one > recv mode happy? > In this case, it is better to disable the delay ack, is this correct? Consistent behavior. A change in message size shouldn't cause a change in on the wire behavior. Either we always send a SACK if we have DATA to send, or we don't. Having a weird "only if it fits" behavior will have unpredictable results. > >> May be we can add some checking to see if there are more chunks that we'll >> be sending and try to bundle it later. >> >> Another question is whether we should really be sending an immediate SACK >> back after receiving just one DATA? >> >> I still think that this should really be handled by SACK immediately extension. >> The extension can apply when we are single sub-MTU packets, essentially a >> request-response scenario. There is no reason that Immediate SACKs can't be >> bundled in this manner. >> > > The immediate SACK is sent without delay SACK timer.It is not generate by > sctp_packet_bundle_sack(), it is created by sctp_gen_sack(). > Matter of implementation. -vlad > > -- 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
