Subject: Any TCP gurus in the house? (RFC1323 and stalling TCP)
To: None <tech-net@netbsd.org>
From: David Brownlee <abs@mono.org>
List: tech-net
Date: 01/06/2000 00:43:42
---------- Forwarded message ----------
Date: 31 Dec 1999 01:23:41 -0000
From: jwbirdsa@picarefy.com
To: gnats-bugs@gnats.netbsd.org
Subject: kern/9085: enabling RFC1323 support causes some TCP connections to
    stall


>Number:         9085
>Category:       kern
>Synopsis:       enabling RFC1323 support causes some TCP connections to stall
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 30 17:27:00 1999
>Last-Modified:
>Originator:     James Birdsall
>Organization:
>Release:        1.4
>Environment:
System: NetBSD picarefy 1.4 NetBSD 1.4 (GENERIC3X) #186: Sat May 8 11:38:37 PDT 1999 root@eighty:/play/gwr/netbsd/build/sun3/GENERIC3X sun3
System connected via Ethernet to a 386 running Linux which is the PPP
gateway (over ISDN) to the outside world.


>Description:
When RFC1323 support is enabled (by default), TCP connections which
negotiate use of the IP timestamp option may stall: there is more data
waiting on the remote host to be sent, and all data received has been ACKed
correctly, but the data will never be sent unless the local host sends data
to the remote host.

   With RFC1323 support on:

08:47:59.440001 timka.picarefy.com.65531 > ringtail.fur.com.2069: S [tcp sum ok] 825968864:825968864(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 4443606 0> [tos 0x10] (ttl 64, id 63343)
08:47:59.550001 ringtail.fur.com.2069 > timka.picarefy.com.65531: S [tcp sum ok] 1112992345:1112992345(0) ack 825968865 win 16060 <mss 1460,nop,nop,timestamp 1436791049 4443606,nop,wscale 0> (DF) (ttl 49, id 62419)
08:47:59.550002 timka.picarefy.com.65531 > ringtail.fur.com.2069: . [tcp sum ok] ack 1 win 17520 <nop,nop,timestamp 4443606 1436791049> [tos 0x10] (ttl 64, id 63344)
08:47:59.680001 ringtail.fur.com.2069 > timka.picarefy.com.65531: P [tcp sum ok] 1:12(11) ack 1 win 16060 <nop,nop,timestamp 1436791061 4443606> (DF) (ttl 49, id 62423)
08:47:59.730001 timka.picarefy.com.65531 > ringtail.fur.com.2069: . [tcp sum ok] ack 12 win 17520 <nop,nop,timestamp 4443606 1436791061> [tos 0x10] (ttl 64, id 63345)
08:47:59.800001 ringtail.fur.com.2069 > timka.picarefy.com.65531: P 12:760(748) ack 1 win 16060 <nop,nop,timestamp 1436791061 4443606> (DF) (ttl 49, id 62424)
08:47:59.930001 timka.picarefy.com.65531 > ringtail.fur.com.2069: . [tcp sum ok] ack 760 win 17520 <nop,nop,timestamp 4443607 1436791061> [tos 0x10] (ttl 64, id 63346)
08:48:02.810001 ringtail.fur.com.2069 > timka.picarefy.com.65531: P 1:760(759) ack 1 win 16060 <nop,nop,timestamp 1436791361 4443606> (DF) (ttl 49, id 62440)
08:48:02.810002 timka.picarefy.com.65531 > ringtail.fur.com.2069: . [tcp sum ok] ack 760 win 17520 <nop,nop,timestamp 4443612 1436791061> [tos 0x10] (ttl 64, id 63350)
[...]
08:48:28.360001 ringtail.fur.com.2069 > timka.picarefy.com.65531: P 2787:4235(1448) ack 6 win 16060 <nop,nop,timestamp 1436793901 4443663> (DF) (ttl 49, id 62739)
08:48:28.460001 timka.picarefy.com.65531 > ringtail.fur.com.2069: . [tcp sum ok] ack 4235 win 16072 <nop,nop,timestamp 4443664 1436793901> [tos 0x10] (ttl 64, id 63357)
08:48:28.620001 ringtail.fur.com.2069 > timka.picarefy.com.65531: P 4235:5683(1448) ack 6 win 16060 <nop,nop,timestamp 1436793901 4443663> (DF) (ttl 49, id 62740)
08:48:28.650001 timka.picarefy.com.65531 > ringtail.fur.com.2069: . [tcp sum ok] ack 5683 win 14624 <nop,nop,timestamp 4443664 1436793901> [tos 0x10] (ttl 64, id 63358)
08:48:29.240001 timka.picarefy.com.65531 > ringtail.fur.com.2069: . [tcp sum ok] ack 5683 win 15648 <nop,nop,timestamp 4443665 1436793901> [tos 0x10] (ttl 64, id 63359)
08:48:29.700001 timka.picarefy.com.65531 > ringtail.fur.com.2069: . [tcp sum ok] ack 5683 win 16672 <nop,nop,timestamp 4443666 1436793901> [tos 0x10] (ttl 64, id 63360)

   At this point, no further data is ever received.

   With RFC1323 support off:
08:46:42.630001 timka.picarefy.com.65532 > ringtail.fur.com.2069: S [tcp sum ok] 370715114:370715114(0) win 16384 <mss 1460> [tos 0x10] (ttl 64, id 63311)
08:46:48.160001 timka.picarefy.com.65532 > ringtail.fur.com.2069: S [tcp sum ok] 370715114:370715114(0) win 16384 <mss 1460> [tos 0x10] (ttl 64, id 63317)
08:46:48.260001 ringtail.fur.com.2069 > timka.picarefy.com.65532: S [tcp sum ok] 1049914556:1049914556(0) ack 370715115 win 16060 <mss 1460> (DF) (ttl 49, id 61287)
08:46:48.260002 timka.picarefy.com.65532 > ringtail.fur.com.2069: . [tcp sum ok] ack 1 win 17520 [tos 0x10] (ttl 64, id 63318)
08:46:48.400001 ringtail.fur.com.2069 > timka.picarefy.com.65532: P [tcp sum ok] 1:12(11) ack 1 win 16060 (DF) (ttl 49, id 61291)
08:46:48.400002 timka.picarefy.com.65532 > ringtail.fur.com.2069: . [tcp sum ok] ack 12 win 17509 [tos 0x10] (ttl 64, id 63319)
08:46:48.550001 ringtail.fur.com.2069 > timka.picarefy.com.65532: P 12:760(748) ack 1 win 16060 (DF) (ttl 49, id 61292)
08:46:48.610001 timka.picarefy.com.65532 > ringtail.fur.com.2069: . [tcp sum ok] ack 760 win 16772 [tos 0x10] (ttl 64, id 63320)
[...]
08:46:53.110001 ringtail.fur.com.2069 > timka.picarefy.com.65532: P 4267:5727(1460) ack 6 win 16060 (DF) (ttl 49, id 61332)
08:46:53.210001 timka.picarefy.com.65532 > ringtail.fur.com.2069: . [tcp sum ok] ack 5727 win 16966 [tos 0x10] (ttl 64, id 63329)
08:46:53.300001 ringtail.fur.com.2069 > timka.picarefy.com.65532: P 5727:7011(1284) ack 6 win 16060 (DF) (ttl 49, id 61333)
08:46:53.380001 timka.picarefy.com.65532 > ringtail.fur.com.2069: . [tcp sum ok] ack 7011 win 16706 [tos 0x10] (ttl 64, id 63330)

   All data received OK.

>How-To-Repeat:
Find a remote host which also has RFC1323 support and verify via tcpdump
that connections negotiate use of IP timestamps. Such connections appear to
always exhibit the problem, usually sooner than later. If you can find a
relatively well-populated MUCK on such a host, connect to it with the stock
telnet client and do a WHO -- it is rare to get all the way through the
list without observing a stall.

>Fix:
Workaround by disabling RFC1323 support via sysctl.
>Audit-Trail:
>Unformatted: