[e2e] TCP improved closing strategies?

[William Allen Simpson]

Craig Partridge wrote:
> Question first -- why is port cycling an issue?  In TCP, one has to keep
> the tuple <src addr, dst addr, src port, dst port> unique.  To run out
> of ports you'd have to use so many ports with ONE peer that you'd have
> problems..  Seems unlikely (even if a peer is, actually, a NATed network).
> 
I'm not the operator in question, so I don't have the data, but based on a
'phone conversation: [x].gtld-servers.net. (Only the src port varies.)

If a strategy was adopted to vary the query through all [x] possibilities,
there's only 13 of them.  There's a good likelihood of collisions, unless
every OS carries a separate PAWS timestamp for each connection (something
we've mentioned here in the past).

Obviously, there are quite a few older OS out there, and some of them
keep a system-wide PAWS timestamp.


> The second question is why having a hashed PCB in TIME WAIT is such an
> issue for 2 MSL...  (Is it purely the size of the hash database -- if so,
> there are ways to compress the hash table...).
> 
AFAIK, the last survey (6-7 years ago) was 100 million queries per day, so
that's roughly 694,444 during each 2MSL period.  Of course, that's average,
not peak (likely much more)....

http://dns.measurement-factory.com/writings/wessels-pam2003-paper.pdf

We're talking about Linux, Solaris, HP-UX, AIX, maybe some others. Do all
these servers have the capability to handle that many TCP connections,
rather than UDP connections?

Do *any* of them?


> That said, the problem is fun.
> 
> As I recall Andy Tanenbaum used to point out that TP4 had an abrupt close
> and it worked.  It does require somewhat more application coordination but
> perhaps we can fake that by, say, retransmitting the last segment and the FIN
> a few times to seek to ensure that all data is received by the client???
> 
Cannot depend on the DNS client's OS to be that smart.  Has to be a server
only solution.  Or based on a new TCP option, that tells us both ends are
smart.  (I've an option in mind.)