{"id":1391,"date":"2011-07-19T08:51:03","date_gmt":"2011-07-19T15:51:03","guid":{"rendered":"http:\/\/www.allegro.com\/?page_id=1391"},"modified":"2013-05-23T19:58:15","modified_gmt":"2013-05-24T02:58:15","slug":"a-discussion-of-mpe-tcp-timers-2","status":"publish","type":"page","link":"https:\/\/allegrosupport.com\/?page_id=1391","title":{"rendered":"A Discussion of MPE TCP Timers"},"content":{"rendered":"

As of: July 11, 2011<\/p>\n

In NMMGR on the NETXPORT.GPROT.TCP screen, one finds the following default<\/em><\/strong> (as delivered from HP) values:<\/p>\n

\r\n  [N]       Checksum Enabled (Y For Yes, N For No)\r\n  [1024 ]   Maximum Number of Connections\r\n  [4]       Retransmission Interval Lower Bound (Secs)\r\n  [180  ]   Maximum Time to Wait For Remote Response (Sec)\r\n  [5  ]     Initial Retransmission Interval (Secs)\r\n  [4  ]     Maximum Retransmissions per Packet<\/pre>\n
These values control how a 3000 reacts in the event it needs to re-send (retransmit) a packet (“chunk”) of data over a TCP\/IP network. These values were established at least<\/em> in the MPE V days (and possibly before that) \u2013 back when only big, important computers were trying to talk to each other. (Unlike today when even your refrigerator thinks it needs to “yack it up” over the internet!) The important thing to understand about these values is that they are perfectly fine and do not need changing because they are never (or rarely) used on an optimally-performing network. However, given that\u2026<\/p>\n
    \n
  1. These days, networks rarely perform optimally, and<\/li>\n
  2. HP Network Engineers have described the above values as “way out of whack”<\/li>\n<\/ol>\n
    …then you should change your TCP values to:<\/p>\n
    \r\n  [Y]       Checksum Enabled (Y For Yes, N For No)\r\n  [4096 ]   Maximum Number of Connections\r\n  [1  ]     Retransmission Interval Lower Bound (Secs)\r\n  [360  ]   Maximum Time to Wait For Remote Response (Sec)\r\n  [2  ]     Initial Retransmission Interval (Secs)\r\n  [8  ]     Maximum Retransmissions per Packet<\/pre>\n
    …and go solve more important problems!<\/p>\n
    However, for those needing a more detailed explanation….<\/p>\n
    The core concept of T<\/strong>ransmission C<\/strong>ontrol P<\/strong>rotocol is \u2013 control<\/strong>. It means that TCP makes every attempt to guarantee<\/em>, via its controls, that the stuff “I” send to “you” over the network actually arrives. When you receive something from me, you politely send a receipt acknowledgement \u2013 and one of the controls mechanisms is satisfied. Another of TCP\u2019s assurance features includes the ability to resend data. This means, in the event that you didn\u2019t get some of what I sent, you simply need to say that you didn\u2019t get it and I\u2019ll gladly send (retransmit) it again.<\/p>\n
    TCP transmission (“I am sending<\/span> stuff to you”) timers come into play on a congested<\/em> network. They establish the bounds (or limits) for a given system. Consider the following from Douglas Comer\u2019s authoritative text on TCP\/IP:<\/p>\n
    Congestion is a condition of severe delay caused by an overload of datagrams at one or more switching points<\/strong> (e.g., at routers). When congestion occurs, delays increase and the router begins to enqueue datagrams until it can route them. We must remember that each router has finite storage capacity and that datagrams compete for that storage (i.e., in a datagram based internet, there is no pre-allocation of resources to individual TCP connections). In the worst case, the total number of datagrams arriving at the congested router grows until the router reaches capacity and starts to drop datagrams.<\/p><\/blockquote>\n
    Mr. Comer\u2019s reference to “switching points” can actually be expanded to the system sending<\/em> data, the system receiving<\/em> data and any network gear (e.g., hubs, routers, switches) sitting in-between. Doesn\u2019t that create a mental picture of mounds of dropped data (grams) lying all over the computer room floor?<\/p>\n
    Going back to the default MPE TCP timers, consider the following scenario \u2013 an MPE system is starting a network connection to another system but receives no<\/strong>ack(nowledgment) from the other system:<\/p>\n
    Original packet transmission... - no ACK...\r\nWait   5.0 seconds\r\n       (per the Initial Retransmission Interval value)<\/em>\r\nTime:  5.0 s:  retry# 1\r\n       (of 5 per the Maximum Retransmissions per Packet value)<\/em>\r\nWait   10.0 seconds\r\n       (because the wait time doubles per TCP\u2019s rules)<\/em>\r\nTime:  15.0 s:  retry# 2\r\nWait   20.0 seconds\r\nTime:  35.0 s:  retry# 3\r\nWait   40.0 seconds\r\nTime:  75.0 s:  retry# 4\r\nWait   80.0 seconds<\/pre>\n
    The last TCP retry packet is sent 75.0 seconds after the original packet! The time to connection failure reporting is 155.0 seconds. In other words, it would take over 2 and a half minutes before the remote command returns with an error! That is a loooooonnnnnnngggg time when waiting and likely beyond the patience limit of most interactive users.<\/p>\n
    With the updated TCP Timers, a “Retransmission Interval Lower Bound ” of [1] gives the best performance in cases where single retransmissions are necessary and a “Maximum Retransmissions per Packet” of [8] gives the enough retransmissions to successfully keep a TCP connection going<\/span> over a network that is not consistent in its performance or quality characteristics. So using the same scenario as above, our updated timers would result in the following:<\/p>\n
    Original packet transmission... - no ACK...\r\nWait    2.0<\/strong> seconds\r\nTime:   2.0 s:  retry# 1\r\nWait    4.0<\/strong> seconds\r\nTime:   6.0 s:  retry# 2\r\nWait    8.0<\/strong> seconds\r\nTime:  14.0 s:  retry# 3\r\nWait   16.0<\/strong> seconds\r\nTime:  30.0 s:  retry# 4\r\nWait   32.0<\/strong> seconds\r\nTime:  62.0 s:  retry# 5\r\nWait   64.0<\/strong> seconds\r\nTime: 126.0 s:  retry# 6\r\nWait  128.0<\/strong> seconds\r\nTime: 254.0 s:  retry# 7\r\nWait  256.0<\/strong> seconds\r\nTime: 510.0 s:  retry# 8\r\nWait  512.0<\/strong> seconds<\/pre>\n
    Our time to wait increased to over 8 minutes.  However, it\u2019s far more likely that we\u2019ll never reach the 8th<\/sup> retry because we\u2019ve requested retries as frequently as allowed on MPE systems.<\/p>\n
    Additional Notes<\/span><\/p>\n
    The disabled Checksum field [N] is another carry-over from olden times. Enabling the checksum function, while it does create some minute overhead, creates a TCP header that is RFC compliant and in-line with other systems\u2019 behavior.<\/p>\n
    Most systems these days benefit from increasing the number of connections to some value greater than 1024. (We recommend 4096). If you are encountering VT Error 39\u2019s \u2013 this is a sign that this value needs to be increased. Do not, however, arbitrarily increase this number to a large value (e.g., 20000) without direction. This value uses real memory and too large a value can cause the system to be unable to start networking.<\/p>\n
    Summary<\/span><\/p>\n
    Between high-speed servers on the same network, these timers rarely come into play. Where these timers \u2013 and their tuning \u2013 are important is with interactive users utilizing PC\u2019s, or servers spread-out over a WAN or even the Internet. The very nature of these connections \u2013 with jerky starts\/stops or heavy traffic \u2013 demand more robust network performance, which the updated timers provide.<\/p>\n
    Acknowledgements<\/span><\/p>\n
    Allegro wishes to gratefully recognize the following people for their invaluable contributions to this paper:<\/p>\n