Re: `tcpdump` host-host

Richard B. Johnson (root@chaos.analogic.com)
Tue, 24 Mar 1998 08:24:38 -0500 (EST)


On Mon, 23 Mar 1998, David S. Miller wrote:

>
> I checked out these dumps, and here is what I see. I am assuming that
> 204.178.40.143 is your Sun box, and 204.178.40.224 is the Linux-2.1.90
> machine, am I correct?
>
Yes correct.

> Anyways, I think the bug is in the TCP code running on the Sun, here
> is an example snippet:

[SNIPPED]

>
> I'm sorry, that shows complete bogus data packaging being done by the
> BSD networking running on the Sun (I assume it's running SunOS, the
> data length behavior is very consistant with that of 4.3 BSD stacks).
> And there are even worse segments:
>

You may be correct. But the new Linux ACK policy may tend to bring out
this condition on Suns.

I think that a resonant condition occurs which aggrevates this condition.
Suns-to-Suns do not have this problem. The transmission-length settles
down into a 1500 byte MTU with 1460 data bytes very quickly.

It is possible that changing the response time for the "next" ACK may
dampen this condition. As I see it, if a packet has not been received for
some period of time, the ACK to this packet should not be delayed. For
lack of a better name, I'll call this the "keystroke" condition.

If, however, packets continue to arrive, i.e., continuous data-flow, then
the ACK should be delayed so that two packets can be ACKed at the same
time. But, if there are "missing" time-slots at which packets are not
received as "expected", there should be some way to prevent immediately
bouncing back to "keystroke" packet condition. Perhaps, still another
timer?

> Bleech... In contrast look at how Linux boxes queue things in the same
> situation:
[SNIPPED]

I know. This looks wonderful.

>
> Later on the timing jitters a bit, and we begin to queue smaller
> frames, but we do act consistantly nonetheless, here's a snippet of
> this behavior:
>
> 204.178.40.236.19 > 204.178.40.224.1118: P 59718:60458(740) ack 1 win 31856 <nop,nop,timestamp 5148732 6063799> (DF) (ttl 64, id 31965)
> 204.178.40.236.19 > 204.178.40.224.1118: P 60458:61198(740) ack 1 win 31856 <nop,nop,timestamp 5148732 6063799> (DF) (ttl 64, id 31966)
> 204.178.40.236.19 > 204.178.40.224.1118: P 61198:61938(740) ack 1 win 31856 <nop,nop,timestamp 5148732 6063799> (DF) (ttl 64, id 31967)
> 204.178.40.236.19 > 204.178.40.224.1118: P 61938:62678(740) ack 1 win 31856 <nop,nop,timestamp 5148732 6063799> (DF) (ttl 64, id 31968)
> 204.178.40.224.1118 > 204.178.40.236.19: . ack 62678 win 28960 <nop,nop,timestamp 6063801 5148732> (DF) (ttl 64, id 35045)
>
> It's a side effect of the speed of the ACK'ing clock coming back to
> the sender, and how quickly the process does it's writes. Essentially
> the congestion window has opened up wide enough that the sending TCP
> can put the packets onto the wire before the process can sneak in and
> and do another write. If the process gets there early enough, we can
> take his short write onto the end of a packet which still has not gone
> out. This _is_ happening above, which is why the data gets clumped
> into nice 1436 byte at a time packets.
>
> There is a little comment in tcp_do_sendmsg() which mentions that we
> perhaps might want to come up with a heuristic which sometimes
> intelligently holds back the sends a little to allow the full
> collapsing of data to occur (ie. long enough for the process to do
> a few more tiny writes).

> Anyways, at this point I say it's a SunOS bug... if it's going to
> package the writes into packets of that size, there isn't much our
> ACKing policy as a receiver can do to alleviate the situation.

> (BTW: For the SunOS-->Linux dumps, where did you do the sniffing, on
> the Linux machine, on the SunOS one, or on some other host? If on
> some other host where was it in relation to the two machines doing
> the transfer?)

The shiffing was none on a Linux 1.1.90 machine, not involved in any
network transactions. This is why I mentioned on my first response that
I had to go to my work site to get you the data you needed.

Cheers,
Dick Johnson
***** FILE SYSTEM MODIFIED *****
Penguin : Linux version 2.1.90 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu