From owner-freebsd-hackers Mon Jan 16 11:17:36 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA03454 for hackers-outgoing; Mon, 16 Jan 1995 11:17:36 -0800 Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id LAA03422 for ; Mon, 16 Jan 1995 11:17:20 -0800 Received: from utis156.cs.utwente.nl by utrhcs.cs.utwente.nl (5.0/csrelayMX-SVR4_1.0/RB) id AA04603; Mon, 16 Jan 1995 13:30:23 --100 Received: by utis156.cs.utwente.nl (4.1/RBCS-1.0.1) id AA21233; Mon, 16 Jan 95 13:30:13 +0100 To: Garrett Wollman Cc: hackers@FreeBSD.org Subject: Netinet internals (Was: Patching a running kernel) In-Reply-To: Your message of Fri, 13 Jan 1995 15:07:10 EST Date: Mon, 16 Jan 1995 13:30:08 +0100 Message-Id: <21232.790259408@utis156> From: Andras Olah content-length: 0 Sender: hackers-owner@FreeBSD.org Precedence: bulk On Fri, 13 Jan 1995 15:07:10 EST, Garrett Wollman wrote: > Create a sysctl interface for it. It's trivial to do. Thanks, done. > -GAWollman > > PS: How's T/TCP coming? (FYI: T/TCP is an extension of TCP for transactions [RFC-1644] I'm trying port to FreeBSD with the help of Garrett. Interested people can get the current - buggy - code from me. My observations with stock 2.0 networking code maybe interesting for people on this list, so I cc'd it to hackers.) A bit slowly, I'm sorry for it. I haven't had much time since the status report I forwarded to you before X-mas (I hope you got it). It seems that I have to dive deeper into tcp_input/tcp_output to really understand what goes wrong. During the last week, I made some experiments with the stock 2.0 code and found some problems. I want to straighten them out before further debugging the T/TCP extensions. /* * If this is a small packet, then ACK now - with Nagel * congestion avoidance sender won't send more until * he gets an ACK. */ if ((unsigned)ti->ti_len < tp->t_maxseg) { tp->t_flags |= TF_ACKNOW; tcp_output(tp); } else { tp->t_flags |= TF_DELACK; } The above code fragment from tcp_input (in the header pred code and at the end of the `slow' path) has a number of bad effects (1) every character in telnet sessions is echoed in two packets (immediate ACK and then the echoed character); (2) in bulk transfer (series of full sized packets) when options are used: because ti_len = maxseg - length of options every packet will be acked immediately, and window updates after application reads will always be in a separate packet. Thus in short, all the advantages of delayed ACKs are lost. The alignment by rounding of the MSS to a nice value in tcp_mss is also lost if options are used, because the actual data length in packets will be MSS - options. This is less important now because the ethernet MTU is less than MCLBYTES, but will decrease efficiency over ATM or FDDI, for example. Finally, even if I switch off the do_rfc1323 flag (to assure that MSS sized packets are sent), I don't quite understand the implementation of delayed acks. Using ttcp with 16k read/writes on the loopback interface (MTU set to 1500), I collected traces where 10 segments were sent in a series and then the receiver acked them in one ACK. Isn't it a violation of RFC-1122 which requires that at least every second MSS sized segment should be acked? I couldn't find any code in tcp_input that set ACKNOW or needoutput when two MSS sized segments were received since the last ACK was sent. Did I miss something here? Andras