On Sun, 5 Apr 2009, sth...@nethelp.no wrote:

On 7-STABLE, with kern.ipc.maxsockbuf=2621440, both sides set a window
scaling factor of 6 (i.e. SYN wscale 6, SYN-ACK wscale 6) using IPv4.

With the same value of kern.ipc.maxsockbuf, using IPv6, the side which
sends the initial SYN sets a window scaling factor of only 1, while
the other side sets a scaling factor of 6 in the SYN-ACK. This will
obviously limit throughput in many cases.

In both cases net.inet.tcp.rfc1323=1.

Anybody know why IPv6 behaves differently here?

tcpdump example:

22:20:37.282415 IP 193.75.4.50.53981 > 193.75.110.66.5555: S 1580765626:1580765626(0) 
win 65535 <mss 1460,nop,wscale 6,sackOK,timestamp 661320721 0>
22:20:37.282442 IP 193.75.110.66.5555 > 193.75.4.50.53981: S 1408884711:1408884711(0) 
ack 1580765627 win 65535 <mss 1460,nop,wscale 6,sackOK,timestamp 1581013561 
661320721>

22:21:49.749586 IP6 2001:8c0:9a00:1::2.53983 > 2001:8c0:8500:1::2.5555: S 
565631163:565631163(0) win 65535 <mss 1440,nop,wscale 1,sackOK,timestamp 661393190 
0>
22:21:49.749633 IP6 2001:8c0:8500:1::2.5555 > 2001:8c0:9a00:1::2.53983: S 
627173961:627173961(0) ack 565631164 win 65535 <mss 1440,nop,wscale 
6,sackOK,timestamp 8

I think the answer to tthat is in sys/netinet/tcp_usrreq.c in the
functuoins:
tcp_connect

1106         /*
1107          * Compute window scaling to request:
1108          * Scale to fit into sweet spot.  See tcp_syncache.c.
1109          * XXX: This should move to tcp_output().
1110          */
1111         while (tp->request_r_scale < TCP_MAX_WINSHIFT &&
1112             (TCP_MAXWIN << tp->request_r_scale) < sb_max)

                                                    ^^^^^^^^^^^

1113                 tp->request_r_scale++;


and tcp6_connect

1174         /* Compute window scaling to request.  */
1175         while (tp->request_r_scale < TCP_MAX_WINSHIFT &&
1176             (TCP_MAXWIN << tp->request_r_scale) < so->so_rcv.sb_hiwat)

                                                    ^^^^^^^^^^^

1177                 tp->request_r_scale++;


I'll have to check why they are un-equal...

/bz

--
Bjoern A. Zeeb                      The greatest risk is not taking one.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to