Re: TCP acking too fast

[Mika Liljeberg <Mika.Liljeberg@welho.com>]

kuznet@ms2.inr.ac.ru wrote:
> > Well, I think this "problem" is way overstated.
> 
> Understated. :-)
> 
> Actually, people who designed all this engine always kept in the mind
> only two cases: ftp and telnet. Who did care that some funny
> protocols sort of smtp work thousand times slower than they could?

Well, if you ask me, it's smtp that is a prime example of braindead
protocol design. It's a wonder we're still using it. If you put that
many request-reply interactions into a protocol that could easily be
done in one you're simply begging for a bloody nose. Nagle or not, smtp
sucks. :)

Anyway, Minshall's version of Nagle is ok with smtp as long as the smtp
implementation isn't stupid enough to emit two remants in one go (yeah,
right).

Anyway, it would be interesting to try a (even more) relaxed version of
Nagle that would allow a maximum of two remnants in flight. This would
basically cover all TCP request/reply cases (leading AND trailing
remnant). Coupled with large initial window to get rid of  small-cwnd
interactions, it might be almost be all right.

Assuming the above, we woulnd't need your ack-every-pushed-remnant
policy, except for the following pathological bidirection case:

A and B send two remnants to each other at the same time. Then both
block waiting for ack, until finally one of them sends a delay ack. You
could break this deadlock by using the following rule:

- if we're blocked on Nagle (two remnants out) and the received segment
has PSH, send ACK immediately

In other cases you wouldn't need to ack pushed segments. What do you
think? :-) 

> Alexey

Regards,

	MikaL