Date: Tue, 17 Jan 1995 21:12:23 -0800 From: David Greenman <davidg@Root.COM> To: Andras Olah <olah@cs.utwente.nl> Cc: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>, hackers@FreeBSD.org Subject: Re: Netinet internals (Was: Patching a running kernel) Message-ID: <199501180512.VAA02654@corbin.Root.COM> In-Reply-To: Your message of "Mon, 16 Jan 95 13:30:08 %2B0100." <21232.790259408@utis156>
next in thread | previous in thread | raw e-mail | index | archive | help
>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.
These are obviously both bugs. I didn't notice the echo and the ack
occuring seperately when I analyzed the packet stream after making the
change...so this is a surprise to me. On the other hand, now that you mention
it, it does appear that this is what the code is actually going to do. Hmmm.
The second is an oversight and it should certainly account for any options that
may reduce the length - provided that the sender takes this into account when
deciding whether or not to send. The problem that was originally 'solved' by
these changes was one where interactive usage over ether or other high speed
network connection was 'choppy' because of the 200ms delays inserted into echo
and other short packets (vi was especially bad).
>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?
Indeed, rfc1122 does say "SHOULD"...which makes this behavior not required.
The problem with acking this often is that on high speed, half-duplex networks
like ethernet, the collision rate caused by acks this frequently can consume a
large amount of the banwidth (measured 10-20%).
In the 4.4-lite TCP code, the acks every 2 packets was indirectly caused by
limiting the window to 4K. This had exceptionally bad side effects on long,
slow, high latency connections that are typical on the internet and usually
resulted in connection thrashing (my terminology) - i.e. the connection becomes
bursty and unable to stream.
-DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501180512.VAA02654>