[e2e] TCP improved closing strategies?

William Allen Simpson william.allen.simpson at gmail.com
Thu Aug 13 05:58:23 PDT 2009

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)....


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.)

More information about the end2end-interest mailing list