Re: Do piggybacked ACKs work?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
#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;
}
#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: sctp_bsd72_server.cap
Description: Binary data

Attachment: sctp_linux_server.cap
Description: Binary data


[Index of Archives]     [Linux Networking Development]     [Linux OMAP]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux