Re: Very poor TCP/SACK performance

Re: Very poor TCP/SACK performance

[David S. Miller]

   Date: Tue, 8 Sep 1998 17:10:10 -0400 (EDT)
   From: Jeff DeFouw <mrj@i2k.com>

   On Tue, 8 Sep 1998, David S. Miller wrote:

   > But if you provide more dumps to help me debug this problem could
   > you please rebuild tcpdump with the patch I have appended at the end?
   > The stock tcpdump does not output SACK information from TCP packets
   > properly without the patch.  The stock tcpdump uses the pre-RFC format
   > of the SACKS which is nothing like real modern SACKs in use today :-)

     Did you forget to append the patch, or is there somewhere I can get it?

Sorry, here it is:

--- tcpdump-3.3/tcpdump-3.3/print-tcp.c.orig	Tue Dec 10 23:26:08 1996
+++ tcpdump-3.3/tcpdump-3.3/print-tcp.c	Thu Mar 19 23:46:33 1998
@@ -103,8 +103,8 @@
 	register int hlen;
 	register char ch;
 	u_short sport, dport, win, urp;
-	u_int32_t seq, ack;
-
+	u_int32_t seq, ack,thseq,thack;	
+        int threv;
 	tp = (struct tcphdr *)bp;
 	ip = (struct ip *)bp2;
 	ch = '\0';
@@ -162,7 +162,7 @@
 			tha.port = dport << 16 | sport;
 			rev = 1;
 		}
-
+		threv = rev;
 		for (th = &tcp_seq_hash[tha.port % TSEQ_HASHSIZE];
 		     th->nxt; th = th->nxt)
 			if (!memcmp((char *)&tha, (char *)&th->addr,
@@ -183,6 +183,10 @@
 			else
 				th->seq = seq, th->ack = ack - 1;
 		} else {
+		  
+		        thseq = th->seq;
+                        thack = th->ack;
+
 			if (rev)
 				seq -= th->ack, ack -= th->seq;
 			else
@@ -263,18 +267,32 @@
 				break;
 
 			case TCPOPT_SACK:
-				(void)printf("sack");
-				datalen = len - 2;
-				for (i = 0; i < datalen; i += 4) {
-					LENCHECK(i + 4);
-					/* block-size@relative-origin */
-					(void)printf(" %u@%u",
-					    EXTRACT_16BITS(cp + i + 2),
-					    EXTRACT_16BITS(cp + i));
+			  {
+			    u_int32_t s, e;
+
+			    datalen = len - 2;
+			    if (datalen % 8 != 0) {
+				(void)printf(" malformed sack ");
+			    } else {
+				(void)printf(" sack %d ", datalen / 8);
+				for (i = 0; i < datalen; i += 8) {
+				    LENCHECK(i + 4);
+				    s = EXTRACT_32BITS(cp + i);
+				    LENCHECK(i + 8);
+				    e = EXTRACT_32BITS(cp + i + 4);
+				    if (threv) {
+					s -= thseq;
+					e -= thseq;
+				    } else {
+					s -= thack;
+					e -= thack;
+				    }
+				    (void)printf("{%u:%u}", s, e);
 				}
-				if (datalen % 4)
-					(void)printf("[len %d]", len);
-				break;
+				(void)printf(" ");
+			    }
+			    break;
+			  }
 
 			case TCPOPT_ECHO:
 				(void)printf("echo");

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html

Re: Very poor TCP/SACK performance

[Chris Wedgwood]

On Tue, Sep 08, 1998 at 11:21:17PM +0200, Felix von Leitner wrote:

> Why is Linux using SACK, anyway? Stevens refers to it like "yeah,
> the BSD people implemented it once, but it didn't work so it was
> discarded and is now obsolete".

I think the context of Stevens probably refers to RFC1072, "TCP
Extensions for Long-Delay Paths", section 3.1. This is dated October
1988, some ten years old.

RFC2018 presumably obsoletes this part, and it looks to me like the
more modern SACK description doesn't fit with the earlier one. This
one is October 1996, not so old.

> And, you know, if Stevens says so, I'd be tempted to just accept
> this as God given and be done with it.  What was the reason to add
> SACK support to Linux?  Almost no system under the sun seems to
> support it, anyway. Right?

S. Floyd et al probably know more about SACK than Stevens and have
done recent (5 years or so) research in this area.

http://www-nrg.ee.lbl.gov/floyd/sacks.html has more details and
recent research efforts which tend to indicate SACK is a way cool
thing that will prevent hair loss reduce global warming.



-Chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html