Re: Do piggybacked ACKs work?

["Doug Graham" <dgraham@nortel.com>]

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.