[e2e] TCP improved closing strategies?
touch at ISI.EDU
Tue Aug 18 08:42:32 PDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the end2end-interest