{"id":6907,"date":"2012-03-22T13:28:34","date_gmt":"2012-03-22T13:28:34","guid":{"rendered":"http:\/\/www.beautifulwork.org\/?p=6907"},"modified":"2012-03-22T13:28:34","modified_gmt":"2012-03-22T13:28:34","slug":"tcp_sack-boolean","status":"publish","type":"post","link":"https:\/\/www.trueangle.org\/index.php\/2012\/03\/22\/tcp_sack-boolean\/","title":{"rendered":"tcp_sack – BOOLEAN"},"content":{"rendered":"

A UNIX Parameter<\/u><\/h4>\n
\n$cat tcp_sack\n1\n$\n<\/pre>\n
<\/p>\n
Parameter Definition<\/u><\/h4>\n
\ntcp_sack - BOOLEAN\n Enable select acknowledgments (SACKS).\n\nSACK is  defined by  RFCs 2018, 2883,  and 3517 (see  Resources for\nlinks  to  these  RFCs).  Plain  TCP  (in  other  words,  non-SACK)\nacknowledgments  are  strictly  cumulative-an acknowledgment  of  N\nmeans that  byte N and all  previous bytes have  been received. The\nproblem SACK is meant to address is this \"all or nothing\" nature of\nthe plain cumulative acknowledgment.   For instance, even if packet\n2 (in  a sequence 0  to 9,  say) is the  only packet lost  during a\ntransfer, the  receiver can  issue a plain  ACK only for  packet 1,\nbecause that  is the  highest packet it  received without a  gap. A\nSACK receiver,  on the other  hand, can issue  an ACK for 1  plus a\nSACK option for  packets 3 through 9. This  extra information helps\nthe sender determine that the losses are fairly minimal and that it\nonly needs to  retransmit a little bit of  data. Without this extra\ninformation, it  would need to  retransmit much more data  and slow\ndown its  sending rate to  accommodate what looks like  a high-loss\nnetwork.\n\nsource: http:\/\/www.ibm.com\/developerworks\/linux\/library\/l-tcp-sack\/index.html\n<\/pre>\n
<\/p>\n
Parameter Code Internals<\/u><\/h4>\n
\n\/* If data was SACKed, tag it and see if we should send more data.\n         * If data was DSACKed, see if we can undo a cwnd reduction.\n         *\/\n        if (TCP_SKB_CB(skb)->sacked) {\n                flag |= tcp_sacktag_write_queue(sk, skb, prior_snd_una);\n                newly_acked_sacked = tp->sacked_out - prior_sacked;\n                tcp_fastretrans_alert(sk, pkts_acked, newly_acked_sacked,\n                                      is_dupack, flag);\n        }\n\n<\/pre>\n
<\/p>\n
Related From Research Paper<\/u><\/h4>\n
\nAbstract\u2014The standard transmission control protocol(TCP)\ncan not distinguish between the random packet losses due to\nhigh bit error rate(BER) and the packet losses due to network\ncongestion. TCP responds to all losses by invoking congestion\ncontrol and avoidance algorithms, resulting in degraded\nend-to-end performance in wireless and lossy systems.\nMeanwhile, the performance of TCP would be deteriorated\nvery much when it suffered from multi-packets losses in a\nsingle transmission window. This paper propose a\nmodification over TCP_SACK version,we called it MSACK.\nWhen MSACK cooperates with the router configured with\nexplicit congestion notification(ECN), it is capable of\ndistinguishing the wireless packet losses from the congestion\npacket losses, and reacting accordingly. At the same time,\nMSACK adopts available bandwidth algorithm at data sender\nto optimize cwnd and ssthresh in order to avoiding lower slow\nstart threshold when packet losses occured. On the other hand,\nthe performance of MSACK in wireless environment can be\nimproved by taking  advantage of retransmission and\nrestoration in SACK version when TCP encountered\nmulti-packets losses in a single transmission window. The\nsimulations in this paper show that the modification of TCP is\nfeasible, and the performance of TCP is improved actually.\n\nsource :\nPerformance Research and Improvement of TCP_SACK in Wireless Environment\nHu Han\nPhysics & Electronics Information Technology Department\nXiangfan University\nXiangfan?China\nxfhuhan@163.com\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
A UNIX Parameter $cat tcp_sack 1 $ Parameter Definition tcp_sack – BOOLEAN Enable select acknowledgments (SACKS). SACK is defined by RFCs 2018, 2883, and 3517 (see Resources for links to these RFCs). Plain TCP (in other words, non-SACK) acknowledgments are strictly cumulative-an acknowledgment of N means that byte N and all previous bytes have been … <\/p>\n
Continue reading “tcp_sack – BOOLEAN”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/posts\/6907"}],"collection":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/comments?post=6907"}],"version-history":[{"count":0,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/posts\/6907\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/media?parent=6907"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/categories?post=6907"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/tags?post=6907"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}