hi fooler,
thanks for the informative response.
i wonder what is your "elegant" solution to that. =) does the bug still exists
even today after recent kernel release?
thanks!
________________________________
From: fooler mail <[email protected]>
To: Philippine Linux Users' Group (PLUG) Technical Discussion List
<[email protected]>
Sent: Thursday, June 23, 2011 10:22 AM
Subject: Re: [plug] tcp_tw_reuse
On Wed, Jun 22, 2011 at 11:36 PM, hard wyrd <[email protected]> wrote:
> If you're referring to tcp_fin_timeout, then I agree it's a strict violation
> of the TCP spec (which honestly is just a guide anyway and not a contract).
> Vendors violate spec from time to time (eg. put your favorite vendor here).
nope.. RFCs guide vendors to comply and not to violate it.. thats the
main purpose of RFC... vendors fix it if they violated a
specification...
> I'm asking about tcp_tw_reuse not tcp_fin_timeout which I'm not using (yet).
im not even talking of tcp_fin_timeout... maybe you are just confuse
of other respondents...
> Going back to my question. Why should you or should you not use
> tcp_tw_reuse? Let's not focus on what my purposes for asking this question
> for now :). Your thoughts will be appreciated.
> Ciao!
sure... let me explain the mechanics of time wait state so that you
can decide later on if you really wanted to use it or not...
in tcp.. there are two kinds to release a connection...
1. abortive release
2. orderly release
in abortive release.. either of the end hosts can send a reset (RST)
segment to abort the connection immediately...
in orderly release.. both sides send finish (FIN) segments and
acknowledge (ACK) it for normal release of their connection...
time wait state occured in number 2.. diagram below show the orderly
release of a connection...
1) Host A -----> FIN -----> Host B
2) Host A <----- ACK <----- Host B
3) Host A <------ FIN <----- Host B
4) Host A -----> ACK -----> Host B
the one who first send FIN segment is the one doing the active close
and the other side is doing the passive close.. host A is doing the
active close.. host A can either be a client or a server.. either of
them can initiate an active close (as well as simultaneous active
close)
time wait state occured in number 3 when host A recieved FIN segment
of host B.. after that... host A send the final ACK to host B (number
4)....
when host B received the final ACK from host A... it destroys the
socket pair that created for that connection and return the resource
back to the kernel..
but in host A.... socket is not yet destroyed until time to wait is
over (expired)...
the main purpose of time wait state is that in case host B didnt
receive the final ACK of host A (eg. lost in transit).. host B
retransmit or resend its FIN segment again to host A... host A cannot
destroy its socket pair immediately after sending the final ACK as
there is no way for host A to determined if host B received its final
acknowledgment.. that is why host A *must* wait before destroying its
socket pair according to RFC TCP specification... that is why a direct
violation of TCP specification and that is why a note in tcp_tw-reuse
documenation warns you of using that feature...
another purpose of time wait state is to prevent from socket pair reuse..
socket pair is consist of source ip, source port, destination ip and
destination port... time wait state preventing to reuse the same value
of socket pair...
that is why im asking you what are you trying to accomplish as time
wait reuse is not the soluton to your problem in the sense that it
already violated the TCP specification...
i bump this kind of problem when i joined a global company offering a
new service where millions (and perhaps billions) of transactions per
day occured... the aggressive host doing a socket pair reuse because
it can easily runs out those ephemeral ports (64k) due to extremely
high transactions... the aggressive host is a cisco loadbalancer
communicating to a cluster of linux servers on the same network
segment... i discovered this problem when they escalated the problem
to me and i asked them a 1 minute tcpdump on that network segment....
the problem here is not the loadbalancer as it is using an abortive
release to destroy the conneciton immediately towards linux servers
(so no time wait state occured here) so that it can reuse the same
socket pair again.. the problem is on linux servers having a bug on
its tcp/ip stack... i havent submit a bug to redhat as it will takes
time to fix the bug but instead i provided an elegant solution to
their problem...
so you know now the mechanics and you have sound judgement if you want
to use that time wait reuse or not...
fooler.
>
>
>
> On Wed, Jun 22, 2011 at 10:50 AM, fooler mail <[email protected]> wrote:
>>
>> On Tue, Jun 21, 2011 at 5:11 PM, hard wyrd <[email protected]> wrote:
>> > Hi all,
>> > Would enable set /proc/sys/net/ipv4/tcp_tw_reuse ? Why or why not?
>> > Your thoughts will be appreciated. Thanks!
>> > - HW
>>
>> if you can give us an idea what are you trying to accomplish and we
>> will let you understand if this time wait reuse is good for you or
>> not... perhaps you have a problem that time wait reuse is not the
>> actual solution...
>>
>> basically, time wait reuse is a direct violation of TCP specification...
>>
>> fooler.
>> _________________________________________________
>> Philippine Linux Users' Group (PLUG) Mailing List
>> http://lists.linux.org.ph/mailman/listinfo/plug
>> Searchable Archives: http://archives.free.net.ph
>
>
>
> --
> -------------------------------------------------------------
> "Penguin, penguin, and more penguin !"
>
> http://www.webhostadmins.com
> http://www.madforubuntu.com
> http://baudizm.blogsome.com
>
> _________________________________________________
> Philippine Linux Users' Group (PLUG) Mailing List
> http://lists.linux.org.ph/mailman/listinfo/plug
> Searchable Archives: http://archives.free.net.ph
>
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
http://lists.linux.org.ph/mailman/listinfo/plug
Searchable Archives: http://archives.free.net.ph
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
http://lists.linux.org.ph/mailman/listinfo/plug
Searchable Archives: http://archives.free.net.ph
