On Tue, Jul 28, 2009 at 11:13:05AM -0400, Vlad Yasevich wrote: > Doug Graham wrote: > > Hello, > > > > I have a little test that simply has a client send 32 bytes of data to > > server, which then replies back with the same data. What doesn't look > > right to me is that I never see piggybacked ACKs. I see the client > > send 32 bytes, then the server reply in a packet containing a single > > DATA chunk of 32 bytes, and then 200ms later both SACKs are sent. > > Piggybacked ACKs will not be sent every packet. Looks like you are hitting > the typical single packet request-response senario. > > I'd recommend you read RFC 4960 section 6.2. > > Now, it's possible to do some piggy-backing when bulk data is flowing in > both directions, but that would different then you proposal below. I did a fairly quick scan of section 6.2 in RFC 4960, and I'm not sure what I'm supposed to see in there that would clear this up. I still think that section 6.1 applies: 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. See Section 6.2. I still don't understand what "a_rwnd > rwnd" has to do with whether or not a SACK should be appended. Could you tell me specifically which part of section 6.2 you think should prevent SACKs from being piggybacked in a single packet request-response scenario? Note that I've also run my simple test program on the only other implementation of SCTP that I have access to, that on FreeBSD 7.2, and it does piggyback SACKS in the way I expect. To me, it makes no sense to ever skip the piggybacking of a SACK if you've got one to send. The whole point of delayed SACKs is to make this possible, and thus avoid sending a SACK in a separate packet. Here's one case where this lack of SACK piggybacking can have a big performance impact. Suppose C(lient) and S(erver) are sending small requests and replies between each other as quickly as possible. ie: S sends a reply as soon as it gets a request from C, and C sends another request as soon as it gets the previous reply from S. If Nagle is not disabled, what happens is this: C sends request DATA to S S sends reply DATA to C C and S send SACKs to each other after 200ms After the 200ms delay introduced above, A finally has the SACK to its first request, and only now, by the rules of Nagle, can it send another request. So there's a delay of 200ms in request/reply cycle. If S had piggybacked a SACK on the DATA it sent to C, then C would have its SACK when it got S's reply and could send another request immediately after receiving the reply to the first. And if C piggybacks a SACK onto its second request, then S doesn't need to wait for a SACK timeout before it can send the second reply. There's also bandwidth wasted by sending separate SACK packets. Thanks for your reply, Doug. -- 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
