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? > 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(). -- 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
