Loading ...
Sorry, an error occurred while loading the content.
 

Persist Mode

Expand Messages
  • Martin McSweeney
    Hello, my question regards the persist mode feature of TCP. In general, sending a zero window acknowledgement forces a sender into persist mode, and a
    Message 1 of 3 , Jun 18, 2001
      Hello, my question regards the persist mode feature of TCP.

      In general, sending a zero window acknowledgement forces a sender into
      persist mode, and a subsequent acknowledgement re-opens the send window.
      I have found that in some implementations (AIX 4.3 and SunOS 5.6, for
      example), sending a zero window acknowledgment that moves the right
      edge of the send window left still forces the sender into persist mode.
      Once another acknowledgement re-opens the window, all segments that were
      moved to the right of the send window are retransmitted immediately
      (because congestion control mechanism are not invoked).

      However, with other implementations (Linux, for example), behavior is
      quite the opposite. It seems that Linux does not enter persist mode unless
      a zero window acknowledgement acknowledges all outstanding bytes.
      Even if a zero window acknowledgement does put a sender into persist mode,
      Linux will not freeze its transmission rate, but rather use slow-start to
      recover losses. I think the idea behind this is from RFC 2861---a pause in
      communication invalidates the congstion window.

      Does anyone have a comment an how an implementation should re-act to a
      zero window acknowledgement? RFC 1122 is very brief on this subject.

      Thank you,
      Martin McSweeney
    • Charles Esson
      1) Somewhere in the mile high stack of paper that represents the TCP standard it says that the receiver is not allowed to reduce it s advertised window. 2)
      Message 2 of 3 , Jun 18, 2001
        1) Somewhere in the mile high stack of paper that represents the TCP standard
        it says that the receiver is not allowed to reduce it's advertised window.

        2) Somewhere else it says the sender is not allowed to expect nice things if
        it transmits past the advertised window.

        If both conditions are met the receiver can't close his window before
        in-flight packets are acked.

        If I am right ( and this is from memory), then all three behave correctly as
        the condition should not arise.

        It would seem AIX4.3 and Sun0S 5.6 throw their hands in the air and wait for
        some sanity. Linux insists you obey rule 1.

        As I only allow the window to move forward I am with linux.

        Martin McSweeney wrote:

        > Hello, my question regards the persist mode feature of TCP.
        >
        > In general, sending a zero window acknowledgement forces a sender into
        > persist mode, and a subsequent acknowledgement re-opens the send window.
        > I have found that in some implementations (AIX 4.3 and SunOS 5.6, for
        > example), sending a zero window acknowledgment that moves the right
        > edge of the send window left still forces the sender into persist mode.
        > Once another acknowledgement re-opens the window, all segments that were
        > moved to the right of the send window are retransmitted immediately
        > (because congestion control mechanism are not invoked).
        >
        > However, with other implementations (Linux, for example), behavior is
        > quite the opposite. It seems that Linux does not enter persist mode unless
        > a zero window acknowledgement acknowledges all outstanding bytes.
        > Even if a zero window acknowledgement does put a sender into persist mode,
        > Linux will not freeze its transmission rate, but rather use slow-start to
        > recover losses. I think the idea behind this is from RFC 2861---a pause in
        > communication invalidates the congstion window.
        >
        > Does anyone have a comment an how an implementation should re-act to a
        > zero window acknowledgement? RFC 1122 is very brief on this subject.
        >
        > Thank you,
        > Martin McSweeney
      • Matt Mathis
        I think we have conflicting standards.... although I agree with your recollection, I believe that strict never retract the window can not be implemented.
        Message 3 of 3 , Jul 5, 2001
          I think we have conflicting standards.... although I agree with your
          recollection, I believe that strict "never retract the window" can not be
          implemented. Consider the following scenario:

          A connection negotiates TCP window scale (e.g. 3, so the window size is
          quantized in steps of 8 bytes).
          After running for awhile with a reasonable window, the receiver stops
          consuming data.
          The sender continues to send data, 1 byte at a time, progressively filling
          the window.
          Under these conditions the right edge of the window can not be maintained at a
          constant position in the sequence space. Following 7 consecutive data packets
          it will advance by one byte. On the 8th, it will retract by 7 bytes.
          (Alternatively, if the TCP rounds windows to MSS, the steps are MSS sized).

          Furthermore when the window finally closes all the way, it will always be due
          to a window retraction.

          If the TCP doesn't behave this way it will violate some other part of RFC1323
          or the base specifications. Therefore every TCP that implements 1323 violates
          rule 1 under some conditions.

          Furthermore any TCP requires strict adherence to rule 1 is broken.

          I believe that this is "well tested" in todays Internet (it happens all the
          time) but nobody has been looking for symptoms.

          Now a question for the readers: what might happen if this rule was formally
          retracted or amended?

          Thanks,
          --MM--

          On Tue, 19 Jun 2001, Charles Esson wrote:

          >
          > 1) Somewhere in the mile high stack of paper that represents the TCP standard
          > it says that the receiver is not allowed to reduce it's advertised window.
          >
          > 2) Somewhere else it says the sender is not allowed to expect nice things if
          > it transmits past the advertised window.
          >
          > If both conditions are met the receiver can't close his window before
          > in-flight packets are acked.
          >
          > If I am right ( and this is from memory), then all three behave correctly as
          > the condition should not arise.
          >
          > It would seem AIX4.3 and Sun0S 5.6 throw their hands in the air and wait for
          > some sanity. Linux insists you obey rule 1.
          >
          > As I only allow the window to move forward I am with linux.
        Your message has been successfully submitted and would be delivered to recipients shortly.