[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)....
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.)
More information about the end2end-interest
mailing list