IPv6 window scaling factor always 1 on initial SYN

[Bjoern A. Zeeb]

On Sun, 5 Apr 2009, sthaug at 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.