From: "Doug Graham" <dgraham@nortel.com>
To: linux-sctp@vger.kernel.org
Subject: Do piggybacked ACKs work?
Date: Sat, 25 Jul 2009 02:09:53 +0000 [thread overview]
Message-ID: <20090725020953.GA17581@nortel.com> (raw)
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.
Looking at the code in net/sctp/output.c I see this:
/* If sending DATA and haven't aleady bundled a SACK, try to
* bundle one in to the packet.
*/
if (sctp_chunk_is_data(chunk) && !pkt->has_sack &&
!pkt->has_cookie_echo) {
if (asoc->a_rwnd > asoc->rwnd)
<append the SACK chunk to the DATA>
The test that is failing is the "a_rwnd > rwnd" test, and I don't
understand that test at all. As far as I know, a_rwnd is the last value
of rwnd that was advertised to the peer, and rwnd is the current receive
window. What's happening is that after the association has settled,
a_rwnd and rwnd are equal. The client then sends 32 bytes to the peer
SCTP on the server. The server SCTP receives these 32 bytes and decreases
its rwnd. Then the userspace server process reads the 32 bytes from the
socket, thus freeing up the buffer space, causing SCTP to increase rwnd back
to where it was initially. When the server process echoes the data,
SCTP constructs a DATA chunk and then runs the above code to see whether
it needs to append a SACK. But since rwnd is no longer less than a_rwnd,
no SACK is sent.
I think this logic is wrong. I don't think the decision as to whether
or not to piggyback a SACK on a DATA packet should have anything to do
with the receive window. If there is unacknowledged data, then the
SACK should be sent, regardless of the state of the receive window.
Am I right about this?
Thanks,
Doug.
next reply other threads:[~2009-07-25 2:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-25 2:09 Doug Graham [this message]
2009-07-28 15:13 ` Do piggybacked ACKs work? Vlad Yasevich
2009-07-28 15:49 ` Doug Graham
2009-07-28 16:09 ` Vlad Yasevich
2009-07-28 20:45 ` Doug Graham
2009-07-28 21:18 ` Michael Tüxen
2009-07-28 22:31 ` Doug Graham
2009-07-28 22:49 ` Doug Graham
2009-07-29 0:06 ` Michael Tüxen
2009-07-29 15:19 ` Vlad Yasevich
2009-07-29 16:07 ` Doug Graham
2009-07-29 16:21 ` Doug Graham
2009-07-29 18:14 ` Vlad Yasevich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090725020953.GA17581@nortel.com \
--to=dgraham@nortel.com \
--cc=linux-sctp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.