[e2e] TCP improved closing strategies?

Joe Touch touch at ISI.EDU
Tue Aug 18 08:42:32 PDT 2009

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.

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


More information about the end2end-interest mailing list