[e2e] TCP improved closing strategies?

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



David P. Reed wrote:
> Minor misunderstanding... I was referring to all of the advanced logic
> and state needed to manage TCP flow control when I mentioned "slow
> start" - and NOT any "artifacts".  The only thing needed for a DNS
> message and response is dealing with assembling an application message
> from a small number of packets.  Both the request and the response (in
> DNS at the application level) make no meaningful change to the state
> variables at either end, so they are commutative and idempotent
> operations with respect to all other DNS requests and all other DNS
> responses.   That makes almost all of the "semantic functionality" of
> TCP irrelevant, and means that "connection state" is flushable.

It means you didn't need TCP. You can't flush TCP state unless you know
you don't need what it provides - notably protection that the next TCP
connection on that socket pair won't be affected by late arriving
segments from the previous connection.

Let's not change TCP semantics in this regard; let's just not use TCP
where TCP semantics aren't needed.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqKy+gACgkQE5f5cImnZrvSDgCguWwCI8I8pfXVKraseGEeNMqP
5QcAnjB/0PB+di2KZUgeRZ7d485aUfZ2
=/M1z
-----END PGP SIGNATURE-----