[HECnet] TCP/IP experts?

[Johnny Billquist]

Hi. As I'm working on my TCP/IP for RSX, I just noticed something that I think looks funny in Linux. But right now my head is also spinning, so maybe there is something I've just forgotten, or don't know, which explains this. But if anyone can shed some light, I'd be interested.

Just for the record - I *think* that TCP/IP in Linux is misbehaving, but it's not really hurting anything, but I like my TCP/IP to really do things as right and optimal as possible.

So, I actually have two scenarios that I'm looking at. The first one is the initial setup. You know, the old three way handshake. Here is a tcpdump between a Linux box and my RSX. Psilo being Linux, and Madame being RSX, and connection initiated from RSX to Linux:

01:02:06.567423 IP Madame.Update.UU.SE.48001 > Psilocybe.Update.UU.SE.http: Flags [S], seq 2810750936, win 5840, options [mss 1460], length 0
01:02:06.567435 IP Psilocybe.Update.UU.SE.http > Madame.Update.UU.SE.48001: Flags [S.], seq 323429751, ack 2810750937, win 14600, options [mss 1460], length 0
01:02:06.569071 IP Madame.Update.UU.SE.48001 > Psilocybe.Update.UU.SE.http: Flags [.], ack 1, win 5840, length 0
01:02:07.966015 IP Psilocybe.Update.UU.SE.http > Madame.Update.UU.SE.48001: Flags [S.], seq 323429751, ack 2810750937, win 14600, options [mss 1460], length 0
01:02:07.967524 IP Madame.Update.UU.SE.48001 > Psilocybe.Update.UU.SE.http: Flags [.], ack 1, win 5840, length 0

Notice how I get two SYN-ACK packets in quick succession from Linux. I ack both, and connection is established. But is there any sane reason why Linux would SYN-ACK twice, and the second one more than a second after the first.
I should point out that the tcpdump is being run on Psilo (the Linux box in question), so the packet definitely found its way to Psilo, so I don't think lost packet is the answer. Also, it is very repeatable.


Second issue. During a session I see the following. Data transferred from RSX to Linux:

01:10:23.065711 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 17521:18981, ack 27, win 5840, length 1460
01:10:23.065715 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 18981, win 52560, length 0
01:10:23.106052 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 18981:20441, ack 27, win 5840, length 1460
01:10:23.106055 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 20441, win 55480, length 0
01:10:23.146201 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 20441:21901, ack 27, win 5840, length 1460
01:10:23.146205 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 21901, win 58400, length 0
01:10:23.181855 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 21901:23361, ack 27, win 5840, length 1460
01:10:23.181859 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 23361, win 61320, length 0
01:10:23.215162 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 23361:24821, ack 27, win 5840, length 1460
01:10:23.215166 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 24821, win 62780, length 0


Notice how Psilo ACKs every fricking message immediately. No delayed ACKs at all. And the announced window is plenty larger. I could have sent another 30 messages before that window was exhausted.
I could possibly believe that in todays world a window of 50K could be considered "almost exhausted" and so immediate window updates when possible, but it do seem a bit silly, and spams the network with lots of unneccesary ACK packets here.

Any thoughts, opinions or knowledge always welcome.

	Johnny

-- 
Johnny Billquist                                   || "I'm on a bus
                                                                  ||   on a psychedelic trip
email: bqt at softjar.se                         ||   Reading murder books
pdp is alive!                                         ||   tryin' to stay hip" - B. Idol