kuznet@ms2.inr.ac.ru wrote:
>
> Hello!
>
> > Well, you should read the preceding messages to understand how we got
> > here.
>
> I am reading now and until now I did not find why problem of calculating
> rcv_mss raised at all. :-)
I think Andi brought it up. I was actually saying that it probably works
most of the time.
> You nicely understood the reason of the problem and
> it is surely not related to rcv_mss in any way. :-)
>
> > When you say "reliably", you should recognize the underlying assumptions
> > as well.
>
> The assumptions are so conservative, that it is not worth to tell about them.
The assumption is that the peer is implemented the way you expect and
that the application doesn't toy with TCP_NODELAY.
> Heuristics does not predict fall of rcv_mss below 536 when sender
> sets PSH on each frame. And it is pretty evident that such prediction
> is impossible theoretically in this sad case. All that we can do is
> to cry and to hold rcv_mss at 536 and to ack each 4th segment on
> with mtu of 256.
Not really. You could do one of two things: either ack every second
segment and leave rcv estimation only for window calculations, or use an
algorithm like the one I outlined. Either approach would work, I think,
and not produce strech acks.
Regards,
MikaL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 15 2001 - 21:00:54 EST