On Friday 01 October 2004 17:42, you wrote:
> Berend De Schouwer wrote:
> > 09:37:41.118891 IP (tos 0x0, ttl 64, id 40414, offset 0, flags [DF],
> > length: 308) 10.16.2.143.32768 > 192.168.4.2.1023: . 1:269(268) ack
> > 1win 5840
> >
> > Send 268 bytes of data, in one segment, in one fragment. 268 is half
> > of the window size, and much less than mss.
> >
> > 09:37:41.118904 IP (tos 0x0, ttl 64, id 40415, offset 0, flags [DF],
> > length: 83) 10.16.2.143.32768 > 192.168.4.2.1023: P 269:312(43) ack
> > 1win
> >
> > Sent a second packet. I assume this is the first (and only) fragment
> > of the second segment. Remainder of the 311 bytes of data.
>
> Those aren't fragments. There is no IP fragmentation in these dumps.
>
> Those two packets are two TCP segments, in the expected order.
>
> > 5840 09:37:41.331573 IP (tos 0x0, ttl 121, id 8308, offset 0,
> > flags [DF], length: 40) 192.168.4.2.1023 > 10.16.2.143.32768: . [tcp
> > sum ok] ack 312 win 16305
> >
> > Ack the first segment.
>
> That packet is ack'ing both segments. See the "ack 312": it
> acknowleges that all data up to position 312 has been received. 312
> is the sequence number of the second data segment. TCP does not need
> to ack every segment.
Doh! That at least means the TCP stack of the OS is all right. Just the app
that is broken.
> > 09:37:41.353036 IP (tos 0x0, ttl 121, id 8312, offset 0, flags [DF],
> > length: 68) 192.168.4.2.1023 > 10.16.2.143.32768: P [tcp sum ok] 1:29
> > (28) ack 312 win 16305
> >
> > Sends me data (but tells me my data is broken.) The rest of the packets
> > are the final ACK, and the FIN sequence.
>
> From a TCP point of view that's fine. I presume the 28 octets are an
> error message from the application, and the application is broken in
> the way Henrik suggested.
I am 100 % sure they read the data once, and don't bother with the rest.
> I don't know the exact reason why MSS is bounded at half the maximum
> window, but it seems quite feasible that would be a critical condition
> beyond which the complex interaction of delay ack/quick ack/silly
> window/estimation/congestion avoidance etc. etc. algoriths would
> behave differently.
>
> It's unfortunate that some of the heuristics in the TCP code aren't
> explained clearly.
I've read most of RFCs 1122, 1191, 1323, and 2001. I won't pretend to
understand them, but they seem to implicitly assume that the window size is
an integer multiple of the mss. In fact, other texts assume the same. There
is some discussion in places (sorry, lost them, used google) about whether it
should be an even multiple.
In particular, various texts recommend window size to be a multiple of mss for
performance reasons. Of course, this is for larger data, and not for 311
bytes of data.
I haven't found an RFC that says RWIN MUST be n * MSS, where n is an integer.
I suspect this code tries to deal with:
( window_size > mss ) AND ( window_size < 2 * mss )
If mss is 1000, and window_size is 1500, it is probably better to send two 750
byte packets, than one 1000, and one 500 byte packet.
I want to special case window_size < mss. If done at the place where mss is
bound by (window_size / 2), and treated as a special case, it /shouldn't/
break anything. It would be nice to replace /shouldn't/ with /won't/.
So, I want to replace
if (tp->max_window && mss_now > (tp->max_window >> 1))
mss_now = max((tp->max_window>>1), 68U - tp->tcp_header_len);
with:
if (tp->max_window && mss_now > (tp->max_window >> 1))
if (mss_now < tp->max_window)
mss_now = max((tp->max_window>>1), 68U - tp->tcp_header_len)
else
mss_now = max(tp->max_window, 68U - tp->tcp_header_len);
Does that make sense?
> -- Jamie
>
> -
> : send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Berend De Schouwer
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
