Re: User Disconnect Issues - Hewlett Packard

This is a discussion on Re: User Disconnect Issues - Hewlett Packard ; Wilson, James Hoffmeister did a great write up on this in Dec. 2001... I don't knowhow to link to it... I hope James is not offended by it, here is a cut and paste... -Craig Subject: QCTerm And Disconnects From: ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: User Disconnect Issues

  1. Re: User Disconnect Issues

    Wilson,

    James Hoffmeister did a great write up on this in Dec. 2001... I don't knowhow to link to it...
    I hope James is not offended by it, here is a cut and paste...

    -Craig

    Subject: QCTerm And Disconnects

    From: "HOFMEISTER,JAMES (HP-USA,ex1)"

    Reply-To:HOFMEISTER,JAMES (HP-USA,ex1)

    Date:Sat, 1 Dec 2001 02:07:21 -0500

    Content-Type:text/plain



    Parts/Attachments:











































    text/plain


    (253 lines)













    Hello Jeff & @ 3000-l,

    Re: QCTerm And Disconnects

    OOPS's I intended on leaving the "Initial Retransmission Interval" at
    the default... but copied the recommendation off a friends system
    since I had already clobbered mine.

    [4 ] Initial Retransmission Interval (Secs)

    Either [2] or [4] will work... [4/5] is a better startup value for a
    "really" poor quality internet link.

    how this works...

    I configured my system for:

    [ 1] Retransmission Interval Lower Bound (Secs)
    [ 180] Maximum Time to Wait For Remote Response (Sec)
    [ 4] Initial Retransmission Interval (Secs)
    [ 6] Maximum Retransmissions per Packet

    Lets assume we have a network problem "directly" following the
    initial connection setup SYN/SYN-ACK/ACK. This is really the only
    time the "Initial Retransmission Interval" comes into play.

    With the configuration above a packet will be retransmitted 6 times
    with an increment of 4 seconds as follows:

    TCP Packet sent...
    **no ACK response received from remote
    4 seconds first retransmission of packet sent
    **no ACK response received from remote
    8 seconds second retransmission of packet is sent (total of 12 seconds)
    **no ACK response received from remote
    16 seconds third retransmission of packet is sent (total of 28 seconds)
    ***no ACK response received from remote
    32 seconds fourth retransmission of packet is sent (total of 60 seconds)
    ***no ACK response received from remote
    64 seconds fifth retransmission of packet is sent (total of 124 seconds)
    ***no ACK response received from remote
    128 seconds sixth retransmission of packet is NOT sent (252 seconds)
    ***The TCP connection is terminated (252 seconds)

    Note: The sixth retransmission of packet is NOT sent since 252 exceeds
    the "Maximum Time to Wait For Remote Response" of 180 seconds.

    The packet has been sent once and retransmitted 5 times and we have not
    received an acknowledge response from the remote host in 252 seconds. The
    TCP connection is terminated.

    ==========

    Now once a connection is established and a few packets have exchanged
    between the local and remote host the "Retransmission Interval" becomes
    a computed value known as the "T_RTX_TIME" (the computation for this
    value is documented in the TCP RFC's and other network reference
    manuals).

    I configured my system for:

    [ 1] Retransmission Interval Lower Bound (Secs)
    [ 180] Maximum Time to Wait For Remote Response (Sec)
    [ 4] Initial Retransmission Interval (Secs)
    [ 6] Maximum Retransmissions per Packet

    If the network connection between the local and remote host is
    functioning and high speed the value of T_RTX_TIME will move from the
    Initial Retransmission Interval [4] towards the Retransmission Interval
    Lower Bound [1] and may be less than this value.

    Note: in the case where the T_RTX_TIME is less than the Retransmission
    Interval Lower Bound [1], then the Retransmission Interval Lower
    Bound will be used. [1] is the lowest possible value on the hp-e3k, so
    on a good quality high speed link the "Retransmission Interval" used will
    typically be Retransmission Interval Lower Bound[1].

    If the network connection between the local and remote host is poor,
    busy or low speed the value of T_RTX_TIME will move to a value greater
    than the Initial Retransmission Interval [4].

    I have found on the hp-e3k that the computed T_RTX_TIME moves very quickly
    from the "Initial Retransmission Interval" to a value lower than the
    "Retransmission Interval Lower Bound" within the amount of network traffic
    for a logon to the hp-e3k.

    Here is the output of a debug macro executed against a TELNET logon to the
    ":" prompt.

    $3f0 ($41) nmdebug > nstcp_cons
    TCP Connections
    **connection count = $10 = #16
    ....
    **Index Connection State Link Src IP Dst IP SSap DSap NWTM
    ******9 $13a.1600 4.4 00050000 0f2c3033 0f7216a2 001705c0
    $b3.4638

    I can tell this is my Telnet connection since the Source Sap is $17 = #23
    which is the telnet port.

    $3f2 ($41) nmdebug > jh_nstcp_con_time $13a.1600
    ------------------------------------------------------------
    [Yes] Checksum Enabled (Y For Yes, N For No)

    [ 1] Retransmission Interval Lower Bound (Secs)
    [ 180] Maximum Time to Wait For Remote Response (Sec)
    [ 4] Initial Retransmission Interval (Secs)
    [ 6] Maximum Retransmissions per Packet
    ------------------------------------------------------------
    ***T_PROTOCOL_STATE : ESTABLISHED
    ***T_IPC_STATE : IPC_ESTABLISHED

    ***T_SRT_TIME : $7a ( 1.000 Seconds)
    ***T_SRT_MDEV : $18 ( 0.196 Seconds)
    ***T_RTX_TIME : $4c ( 0.622 Seconds) <<--

    ***T_STATS.INBOUND_STATS.USER_PKTS : 45 <<--
    ***T_STATS.OUTBOUND_STATS.USER_PKTS : 39 <<--
    ***T_STATS.INBOUND_STATS.CKSUM_ERROR : 0
    ***T_STATS.OUTBOUND_STATS.RTX : 0

    This macro displays the "T_RTX_TIME" which is less than the
    configured "Retransmission Interval Lower Bound" of [1]. it is also
    interesting to see that 45 inbound packets and 39 outbound packets
    have been exchanged to complete a logon with Telnet to the hp-e3k.

    -----

    I performed the same test with NS-VT VTSERVER and here are the results:

    $3fc ($41) nmdebug > nstcp_cons
    TCP Connections
    **connection count = $3 = #3

    **Index Connection State Link Src IP Dst IP SSap DSap NWTM

    ******3 $13a.2940 4.4 00050000 0f2c3033 0f7216a2 06220656
    $b3.4638

    I can tell this is my Telnet connection since the Source Sap is $622 = #1570
    which is the Ns-services VT port.

    $3fd ($41) nmdebug > jh_nstcp_con_time $13a.2940
    ------------------------------------------------------------
    [Yes] Checksum Enabled (Y For Yes, N For No)

    [ 1] Retransmission Interval Lower Bound (Secs)
    [ 180] Maximum Time to Wait For Remote Response (Sec)
    [ 4] Initial Retransmission Interval (Secs)
    [ 6] Maximum Retransmissions per Packet
    ------------------------------------------------------------
    ***T_PROTOCOL_STATE : ESTABLISHED
    ***T_IPC_STATE : IPC_ESTABLISHED

    ***T_SRT_TIME : $4a ( 0.606 Seconds)
    ***T_SRT_MDEV : $19 ( 0.204 Seconds)
    ***T_RTX_TIME : $46 ( 0.573 Seconds) <<--

    ***T_STATS.INBOUND_STATS.USER_PKTS : 8 <<--
    ***T_STATS.OUTBOUND_STATS.USER_PKTS : 10 <<--
    ***T_STATS.INBOUND_STATS.CKSUM_ERROR : 0
    ***T_STATS.OUTBOUND_STATS.RTX : 0

    This macro displays the "T_RTX_TIME" which is less than the
    configured "Retransmission Interval Lower Bound" of [1]. it is also
    interesting to see that 8 inbound packets and 10 outbound packets
    have been exchanged to complete a logon with NS-VT to the hp-e3k.

    In both the cases of Telnet and NS-VT the T_RTX_TIME is less than
    the Retransmission Interval Lower Bound [1] (Secs) by the time a
    logon is complete.

    -----

    Now with the configuration above the T_RTX_TIME is less than the
    "Retransmission Interval Lower Bound" [1] so a packet will be
    retransmitted at the "Retransmission Interval" of [1].

    With the configuration above a packet will be retransmitted 6 times
    with an increment of 1 seconds as follows:

    TCP Packet sent...
    **no ACK response received from remote
    1 seconds first retransmission of packet sent
    **no ACK response received from remote
    2 seconds second retransmission of packet is sent (total of 3 seconds)
    **no ACK response received from remote
    4 seconds third retransmission of packet is sent (total of 7 seconds)
    ***no ACK response received from remote
    8 seconds fourth retransmission of packet is sent (total of 15 seconds)
    ***no ACK response received from remote
    16 seconds fifth retransmission of packet is sent (total of 31 seconds)
    ***no ACK response received from remote
    32 seconds sixth retransmission of packet is sent (total of 62 seconds)
    ***no ACK response received from remote
    ***The TCP connection is terminated (126 seconds)

    The packet has been sent once and retransmitted 6 times and we have not
    received an acknowledge response from the remote host in 126 seconds. The
    TCP connection is terminated.

    Sorry for the confusion... I recommend:
    ================================================== ==========
    [ 1] Retransmission Interval Lower Bound (Secs)
    [ 180] Maximum Time to Wait For Remote Response (Sec)
    [ 4] Initial Retransmission Interval (Secs)
    [ 6] Maximum Retransmissions per Packet
    ================================================== ==========

    If I still have connectivity problems with this configuration, then my
    next action is to look at the NM logfiles to determine what is actually
    happening before I alter the timers further.

    Just for fun... I did a logon and :listf @.@.@,3 with a WRQ VT-3K
    connection to my hp-e3k a-class over a marginal quality isdn link and
    here is what I see:

    $407 ($41) nmdebug > jh_nstcp_con_time $13a.2940
    ------------------------------------------------------------
    [Yes] Checksum Enabled (Y For Yes, N For No)

    [ 1] Retransmission Interval Lower Bound (Secs)
    [ 180] Maximum Time to Wait For Remote Response (Sec)
    [ 4] Initial Retransmission Interval (Secs)
    [ 6] Maximum Retransmissions per Packet
    ------------------------------------------------------------
    ***T_PROTOCOL_STATE : ESTABLISHED
    ***T_IPC_STATE : IPC_ESTABLISHED

    ***T_SRT_TIME : $61 ( 0.795 Seconds)
    ***T_SRT_MDEV : $4 ( 0.032 Seconds)
    ***T_RTX_TIME : $49 ( 0.598 Seconds) <<--

    ***T_STATS.INBOUND_STATS.USER_PKTS : 20
    ***T_STATS.OUTBOUND_STATS.USER_PKTS : 4796
    ***T_STATS.INBOUND_STATS.CKSUM_ERROR : 29 <<--
    ***T_STATS.OUTBOUND_STATS.RTX : 115 <<--

    Hmmm... 29 TCP Checksum errors and 115 TCP retransmissions. This really
    is a poor quality link. I ran the same test with Telnet and really
    saw little difference.

    I hope this helps.

    Regards,

    James Hofmeister
    Hewlett Packard
    Worldwide Technology Network Expert Center
    P.S. My Ideals are my own, not necessarily my employers.

    *






    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  2. Re: User Disconnect Issues

    Thanks Craig for all the help and suggestions so far. We reduced our TCP settings by 25% last week and so far it seems that we are encountering less problems. However, the settings that James has listed below are way below what we have them set at. Oddly though when you are in the TCP screen in NMMGR and read the help for the parameters/settings, they suggest increasingthem if you are having problems. Our settings were high(er) and were probably in response to this type of problem in the past.

    The write up below was very helpful and informative though.

    wilson

    From: Craig Lalley [mailto:mr_lalley@yahoo.com]
    Sent: Monday, November 10, 2008 12:54 PM
    To: Wong, Wilson
    Cc: hp3000-l@raven.utc.edu
    Subject: RE: User Disconnect Issues

    Wilson,

    James Hoffmeister did a great write up on this in Dec. 2001... I don't knowhow to link to it...
    I hope James is not offended by it, here is a cut and paste...

    -Craig
    Subject:

    QCTerm And Disconnects

    From:

    "HOFMEISTER,JAMES (HP-USA,ex1)"

    Reply-To:

    HOFMEISTER,JAMES (HP-USA,ex1)

    Date:

    Sat, 1 Dec 2001 02:07:21 -0500

    Content-Type:

    text/plain

    Parts/Attachments:

    [http://raven.utc.edu/archives/images/b-paperclip.gif]


    text/plain (253 lines)




    Hello Jeff & @ 3000-l,



    Re: QCTerm And Disconnects



    OOPS's I intended on leaving the "Initial Retransmission Interval" at

    the default... but copied the recommendation off a friends system

    since I had already clobbered mine.



    [4 ] Initial Retransmission Interval (Secs)



    Either [2] or [4] will work... [4/5] is a better startup value for a

    "really" poor quality internet link.



    how this works...



    I configured my system for:



    [ 1] Retransmission Interval Lower Bound (Secs)

    [ 180] Maximum Time to Wait For Remote Response (Sec)

    [ 4] Initial Retransmission Interval (Secs)

    [ 6] Maximum Retransmissions per Packet



    Lets assume we have a network problem "directly" following the

    initial connection setup SYN/SYN-ACK/ACK. This is really the only

    time the "Initial Retransmission Interval" comes into play.



    With the configuration above a packet will be

    retransmitted 6 times

    with an increment of 4 seconds as follows:



    TCP Packet sent...

    no ACK response received from remote

    4 seconds first retransmission of packet sent

    no ACK response received from remote

    8 seconds second retransmission of packet is sent (total of 12 seconds)

    no ACK response received from remote

    16 seconds third retransmission of packet is sent (total of 28 seconds)

    no ACK response received from remote

    32 seconds fourth retransmission of packet is sent (total of 60 seconds)

    no ACK response received from remote

    64 seconds fifth retransmission of packet is sent (total of 124 seconds)

    no ACK response received from remote

    128 seconds sixth retransmission of packet is NOT sent (252 seconds)

    The TCP connection is terminated (252 seconds)



    Note: The sixth retransmission of packet is

    NOT sent since 252 exceeds

    the "Maximum Time to Wait For Remote Response" of 180 seconds.



    The packet has been sent once and retransmitted 5 times and we have not

    received an acknowledge response from the remote host in 252 seconds. The

    TCP connection is terminated.



    ==========



    Now once a connection is established and a few packets have exchanged

    between the local and remote host the "Retransmission Interval" becomes

    a computed value known as the "T_RTX_TIME" (the computation for this

    value is documented in the TCP RFC's and other network reference

    manuals).



    I configured my system for:



    [ 1] Retransmission Interval Lower Bound (Secs)

    [ 180] Maximum Time to Wait For Remote Response (Sec)

    [ 4] Initial Retransmission Interval (Secs)

    [ 6] Maximum Retransmissions per Packet



    If the network connection between the local and remote host is

    functioning and high speed the

    value of T_RTX_TIME will move from the

    Initial Retransmission Interval [4] towards the Retransmission Interval

    Lower Bound [1] and may be less than this value.



    Note: in the case where the T_RTX_TIME is less than the Retransmission

    Interval Lower Bound [1], then the Retransmission Interval Lower

    Bound will be used. [1] is the lowest possible value on the hp-e3k, so

    on a good quality high speed link the "Retransmission Interval" used will

    typically be Retransmission Interval Lower Bound[1].



    If the network connection between the local and remote host is poor,

    busy or low speed the value of T_RTX_TIME will move to a value greater

    than the Initial Retransmission Interval [4].



    I have found on the hp-e3k that the computed T_RTX_TIME moves very quickly

    from the "Initial Retransmission Interval" to a value lower than the

    "Retransmission Interval Lower Bound" within the amount of network traffic

    for a logon

    to the hp-e3k.



    Here is the output of a debug macro executed against a TELNET logon to the

    ":" prompt.



    $3f0 ($41) nmdebug > nstcp_cons

    TCP Connections

    connection count = $10 = #16

    ....

    Index Connection State Link Src IP Dst IP SSap DSap NWTM

    9 $13a.1600 4.4 00050000 0f2c3033 0f7216a2 0017 05c0

    $b3.4638



    I can tell this is my Telnet connection since the Source Sap is $17 = #23

    which is the telnet port.



    $3f2 ($41) nmdebug > jh_nstcp_con_time $13a.1600

    ------------------------------------------------------------

    [Yes] Checksum Enabled (Y For Yes, N For No)



    [ 1] Retransmission Interval Lower Bound (Secs)

    [ 180] Maximum Time to Wait For Remote Response (Sec)

    [ 4] Initial Retransmission Interval (Secs)

    [ 6] Maximum Retransmissions per

    Packet

    ------------------------------------------------------------

    T_PROTOCOL_STATE : ESTABLISHED

    T_IPC_STATE : IPC_ESTABLISHED



    T_SRT_TIME : $7a ( 1.000 Seconds)

    T_SRT_MDEV : $18 ( 0.196 Seconds)

    T_RTX_TIME : $4c ( 0.622 Seconds) <<--



    T_STATS.INBOUND_STATS.USER_PKTS : 45 <<--

    T_STATS.OUTBOUND_STATS.USER_PKTS : 39 <<--

    T_STATS.INBOUND_STATS.CKSUM_ERROR : 0

    T_STATS.OUTBOUND_STATS.RTX : 0



    This macro displays the "T_RTX_TIME" which is less than the

    configured "Retransmission Interval Lower Bound" of [1]. it is also

    interesting to see that 45 inbound packets and 39 outbound

    packets

    have been exchanged to complete a logon with Telnet to the hp-e3k.



    -----



    I performed the same test with NS-VT VTSERVER and here are the results:



    $3fc ($41) nmdebug > nstcp_cons

    TCP Connections

    connection count = $3 = #3



    Index Connection State Link Src IP Dst IP SSap DSap NWTM



    3 $13a.2940 4.4 00050000 0f2c3033 0f7216a2 0622 0656

    $b3.4638



    I can tell this is my Telnet connection since the Source Sap is $622 = #1570

    which is the Ns-services VT port.



    $3fd ($41) nmdebug > jh_nstcp_con_time $13a.2940

    ------------------------------------------------------------

    [Yes] Checksum Enabled (Y For Yes, N For No)



    [ 1] Retransmission Interval Lower Bound (Secs)

    [ 180] Maximum Time to Wait For Remote Response (Sec)

    [ 4] Initial Retransmission Interval (Secs)

    [ 6]

    Maximum Retransmissions per Packet

    ------------------------------------------------------------

    T_PROTOCOL_STATE : ESTABLISHED

    T_IPC_STATE : IPC_ESTABLISHED



    T_SRT_TIME : $4a ( 0.606 Seconds)

    T_SRT_MDEV : $19 ( 0.204 Seconds)

    T_RTX_TIME : $46 ( 0.573 Seconds) <<--



    T_STATS.INBOUND_STATS.USER_PKTS : 8 <<--

    T_STATS.OUTBOUND_STATS.USER_PKTS : 10 <<--

    T_STATS.INBOUND_STATS.CKSUM_ERROR : 0

    T_STATS.OUTBOUND_STATS.RTX : 0



    This macro displays the "T_RTX_TIME" which is less than the

    configured "Retransmission Interval Lower Bound" of [1]. it is also

    interesting to see that 8 inbound packets and

    10 outbound packets

    have been exchanged to complete a logon with NS-VT to the hp-e3k.



    In both the cases of Telnet and NS-VT the T_RTX_TIME is less than

    the Retransmission Interval Lower Bound [1] (Secs) by the time a

    logon is complete.



    -----



    Now with the configuration above the T_RTX_TIME is less than the

    "Retransmission Interval Lower Bound" [1] so a packet will be

    retransmitted at the "Retransmission Interval" of [1].



    With the configuration above a packet will be retransmitted 6 times

    with an increment of 1 seconds as follows:



    TCP Packet sent...

    no ACK response received from remote

    1 seconds first retransmission of packet sent

    no ACK response received from remote

    2 seconds second retransmission of packet is sent (total of 3 seconds)

    no ACK response received from remote

    4 seconds third retransmission of packet is sent (total of 7

    seconds)

    no ACK response received from remote

    8 seconds fourth retransmission of packet is sent (total of 15 seconds)

    no ACK response received from remote

    16 seconds fifth retransmission of packet is sent (total of 31 seconds)

    no ACK response received from remote

    32 seconds sixth retransmission of packet is sent (total of 62 seconds)

    no ACK response received from remote

    The TCP connection is terminated (126 seconds)



    The packet has been sent once and retransmitted 6 times and we have not

    received an acknowledge response from the remote host in 126 seconds. The

    TCP connection is terminated.



    Sorry for the confusion... I recommend:

    ================================================== ==========

    [ 1] Retransmission Interval Lower Bound (Secs)

    [ 180] Maximum Time to Wait For Remote Response (Sec)

    [ 4]

    Initial Retransmission Interval (Secs)

    [ 6] Maximum Retransmissions per Packet

    ================================================== ==========



    If I still have connectivity problems with this configuration, then my

    next action is to look at the NM logfiles to determine what is actually

    happening before I alter the timers further.



    Just for fun... I did a logon and :listf @.@.@,3 with a WRQ VT-3K

    connection to my hp-e3k a-class over a marginal quality isdn link and

    here is what I see:



    $407 ($41) nmdebug > jh_nstcp_con_time $13a.2940

    ------------------------------------------------------------

    [Yes] Checksum Enabled (Y For Yes, N For No)



    [ 1] Retransmission Interval Lower Bound (Secs)

    [ 180] Maximum Time to Wait For Remote Response (Sec)

    [ 4] Initial Retransmission Interval (Secs)

    [ 6] Maximum Retransmissions per

    Packet

    ------------------------------------------------------------

    T_PROTOCOL_STATE : ESTABLISHED

    T_IPC_STATE : IPC_ESTABLISHED



    T_SRT_TIME : $61 ( 0.795 Seconds)

    T_SRT_MDEV : $4 ( 0.032 Seconds)

    T_RTX_TIME : $49 ( 0.598 Seconds) <<--



    T_STATS.INBOUND_STATS.USER_PKTS : 20

    T_STATS.OUTBOUND_STATS.USER_PKTS : 4796

    T_STATS.INBOUND_STATS.CKSUM_ERROR : 29 <<--

    T_STATS.OUTBOUND_STATS.RTX : 115 <<--



    Hmmm... 29 TCP Checksum errors and 115 TCP retransmissions. This really

    is a poor quality link. I ran the same test with Telnet and really

    saw little difference.



    I hope this

    helps.



    Regards,



    James Hofmeister

    Hewlett Packard

    Worldwide Technology Network Expert Center

    P.S. My Ideals are my own, not necessarily my employers.




    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


+ Reply to Thread