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
