From: "Doug Graham" <dgraham@nortel.com>
To: linux-sctp@vger.kernel.org
Subject: Re: Do piggybacked ACKs work?
Date: Tue, 28 Jul 2009 22:31:08 +0000 [thread overview]
Message-ID: <20090728223108.GA10007@nortel.com> (raw)
In-Reply-To: <20090725020953.GA17581@nortel.com>
[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]
On Tue, Jul 28, 2009 at 11:18:05PM +0200, Michael T?xen wrote:
> >I don't think that's what the RFC says, but I guess only the
> >author(s) of
> >the RFC could tell us what they really meant. Your interpretation
> >doesn't
> >make any sense to.
>
> Let us see the tracefile and I can tell you if that behaviour is the
> one the authors of the RFC intended...
Heh. I'm guessing that you're one of the authors then? I see you given
credit in RFC 4960, but the only author listed at the top is R. Stewart.
I've attached linux and BSD capture files, and the client and server
test programs. The client just sends a request to the server, and then
waits for a reply. The client loops four times and sleeps 2 seconds
between iterations. I ran the client on a Fedora 10 laptop in all cases
(kernel version 2.6.27.25) and did the wireshark capture on the same
laptop. sctp_bsd72_server.cap is the capture when running the server
on a FreeBSD 7.2 machine. sctp_linux_server.cap is the capture when
running the server on a Fedora 10 desktop machine. A single iteration
with the BSD server looks like:
7 2.000205 10.0.0.15 10.0.0.11 SCTP DATA
8 2.000501 10.0.0.11 10.0.0.15 SCTP SACK DATA
9 2.200484 10.0.0.15 10.0.0.11 SCTP SACK
So one DATA packet from client to server, then the reply data packet
from server to client with a bundled SACK, then the SACK from client
to server to acknowledge the reply. The last SACK does have to wait
for the SACK timer to expire; this is to be expected, since no more
data is sent until the next iteration in a couple seconds.
A single iteration with the Linux server looks like:
7 2.000161 10.0.0.15 10.0.0.12 SCTP DATA
8 2.000495 10.0.0.12 10.0.0.15 SCTP DATA
9 2.199995 10.0.0.15 10.0.0.12 SCTP SACK
10 2.200170 10.0.0.12 10.0.0.15 SCTP SACK
> >In BSD's case, I *did* see it piggyback the SACK.
>
> I guess you did not specify SCTP_DATA_SACK_IMMEDIATELY in the send()
> call...
No, I didn't. If I had, I agree that no piggybacking would have been
possible. That was what I was trying to say: from the trace, it did
not look as though BSD was using the immediate SACK feature.
--Doug.
[-- Attachment #2: client.c --]
[-- Type: text/plain, Size: 1106 bytes --]
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#define PORT 12342
int main(int argc, char **argv)
{
int s, cc, i;
struct sockaddr_in addr;
in_addr_t destaddr = inet_addr("127.0.0.1");
if (argv[1])
destaddr = inet_addr(argv[1]);
if ((s = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)) < 0) {
perror("socket");
exit(1);
}
memset(&addr, '\0', sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = destaddr;
addr.sin_port = htons(PORT);
char buf[] = "yo momma wears army boots";
struct iovec iov[1] = {{.iov_base = buf, .iov_len = sizeof(buf)}};
struct msghdr msg = {
.msg_name = &addr,
.msg_namelen = sizeof(addr),
.msg_iov = iov,
.msg_iovlen = sizeof(iov)/sizeof(iov[0]),
.msg_control = NULL,
.msg_controllen = 0,
.msg_flags = 0
};
for (i = 0; i < 4; i++) {
printf("Sending message to %s\n", inet_ntoa(addr.sin_addr));
if ((cc = sendmsg(s, &msg, 0)) < 0) {
perror("sendmsg");
exit(1);
}
sleep(2);
}
return 0;
}
[-- Attachment #3: server.c --]
[-- Type: text/plain, Size: 1033 bytes --]
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#define PORT 12342
int main(void)
{
int s, cc;
struct sockaddr_in addr;
if ((s = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)) < 0) {
perror("socket");
exit(1);
}
memset(&addr, '\0', sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = INADDR_ANY;
addr.sin_port = htons(PORT);
if (bind(s, (struct sockaddr *) &addr, sizeof(addr)) < 0) {
perror("bind");
exit(1);
}
if (listen(s, 5) < 0) {
perror("listen");
exit(1);
}
for (;;) {
char buf[128];
struct iovec iov[1] = {{.iov_base = buf, .iov_len = sizeof(buf)}};
struct msghdr msg = {
.msg_name = &addr,
.msg_namelen = sizeof(addr),
.msg_iov = iov,
.msg_iovlen = sizeof(iov)/sizeof(iov[0]),
.msg_control = NULL,
.msg_controllen = 0,
.msg_flags = 0
};
printf("Waiting for message\n");
cc = recvmsg(s, &msg, 0);
printf("Got msg, len = %d\n", cc);
sendmsg(s, &msg, 0);
}
}
[-- Attachment #4: sctp_bsd72_server.cap --]
[-- Type: application/octet-stream, Size: 2738 bytes --]
[-- Attachment #5: sctp_linux_server.cap --]
[-- Type: application/octet-stream, Size: 3080 bytes --]
next prev parent reply other threads:[~2009-07-28 22:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-25 2:09 Do piggybacked ACKs work? Doug Graham
2009-07-28 15:13 ` 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 [this message]
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=20090728223108.GA10007@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.