Date: Mon, 16 Jan 1995 13:30:08 +0100 From: Andras Olah <olah@cs.utwente.nl> To: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu> Cc: hackers@FreeBSD.org Subject: Netinet internals (Was: Patching a running kernel) Message-ID: <21232.790259408@utis156> In-Reply-To: Your message of Fri, 13 Jan 1995 15:07:10 EST
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21232.790259408>