Just noticed this while tcpdump'ing a recent telnet (over ppp) session:
17:30:10.799810 209.75.160.90.1025 > 209.75.160.32.telnet: S 3310621889:3310621889(0) win 32488 <mss 536,nop,nop,timestamp 112754 0,wscale 0,eol> (DF)
17:30:10.976449 209.75.160.32.telnet > 209.75.160.90.1025: S 1854400001:1854400001(0) ack 3310621890 win 16768 <mss 1460,nop,wscale 0,nop,nop,timestamp 17611 112754>
...
What are these <nop,nop>'s doing before my timestamps?
Could they be affecting throughput? (two in *each* packet sent/recv'd)
I've never seen this before in 2.1.89, 2.0.29..
Probably just a cool new feature, eh?
It's RFC1323 TCP extensions for high performance. The timestamps
allow round-trip estimates even in the presence of lost packets.
The NOPS are there on purpose to align the timestamp 32-bit values on
4-byte boundaries in the headers, as suggested by the RFC and as also
implemented in just about every other stack which supports timestamps.
If you think these are weird, wait until SACKs (RFC2018) start showing
up on the wire after my next TCP merge to Linus ;-)
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu