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

Re: 'Slow-Start Restart after Idle' draft

Expand Messages
  • Vernon Schryver
    ... Yes, I phrased things badly there. My general claim is that it does not matter whether there is one hop or many, or whether some of the hops are longer or
    Message 1 of 51 , Oct 26, 1998
    • 0 Attachment
      > From: Michael Ridley <mridley@...>


      > > - RTT's (e.g. from a previous connection or measured during the
      > > 3-way handshake) are imperfect, possibly producing false positives
      > > on, e.g. OC-12 metro links, or on bursty LANs. Still, what
      > > alternative is there?


      > I think I must be missing something here, but why do we care if it's
      > an OC-12 link, for instance? Is that a false positive? The goal
      > here is to bypass slow start when appropriate and send the full
      > advertised window so as to maximize use of non-congested links, correct?
      > Assuming that I haven't gotten really confused in all of this, then
      > I would think you'd want to send the max window on the OC-12 if it's RTT
      > was low (often a faster link even than your LAN on both ends).
      >
      > By stating it's a false positive, you make me think that you'd want slow
      > start in such a case- why?

      Yes, I phrased things badly there.

      My general claim is that it does not matter whether there is one hop or
      many, or whether some of the hops are longer or shorter. All that matters
      is that you want a go-fast mode that violates some of the proposed, even
      stronger language enforcing the TCP congestion control and avoidance
      mechanisms when there are sufficiently few, opportunites for congestion
      at the current instant. It would be nice if there the go-fast mode and
      how and when it is invoked were documented, for all of the standard reasons
      standards exist.

      I was trying to concede in those words that a fairly short, fast, but
      somewhat congested link can appear to have a very small RTT, when the RTT
      is measured with a single pair of packets, such as during the 3-way
      handshake.

      The point of a go-fast mode is the extreme case of what started the
      discussions in this mailing list (I think it was here) weeks or months
      ago about increasing the initial window for HTTP. If you have a
      semi-private 1 Gbit/sec link connecting hosts using 500KByte windows and
      1432 byte MSS to move blocks of data, you really do not want to wait for
      175 ACKs before you are using the full window. You use such large windows
      because your bandwidth*delay product is that large or larger, and you are
      going at speeds where much of the delay comes from inside your hosts.
      For example, if your operating system wakes up your application to dump
      to a screen buffer 10 or 20 ms, you want enough data on hand to make it
      worth while. Or consider moving files; most UNIX file systems do not
      deliver or sink GBytes/sec, but some do, and there soon will be more.
      Given today's cheap Gbit Ethernet and $2000 PC's with 100's of MByte of
      RAM, such scenarios are no longer found only among people with $30M CPU's,
      or at least with $B atomic particle detectors. Competative pressures will
      at least entice implementors to discard slow-start in such situations.
      If they are not conservative in how they turn off slow-start, their code
      will also turn it off in the classic cases where it is needed.


      Vernon Schryver vjs@...
    • Vernon Schryver
      ... Yes, I phrased things badly there. My general claim is that it does not matter whether there is one hop or many, or whether some of the hops are longer or
      Message 51 of 51 , Oct 26, 1998
      • 0 Attachment
        > From: Michael Ridley <mridley@...>


        > > - RTT's (e.g. from a previous connection or measured during the
        > > 3-way handshake) are imperfect, possibly producing false positives
        > > on, e.g. OC-12 metro links, or on bursty LANs. Still, what
        > > alternative is there?


        > I think I must be missing something here, but why do we care if it's
        > an OC-12 link, for instance? Is that a false positive? The goal
        > here is to bypass slow start when appropriate and send the full
        > advertised window so as to maximize use of non-congested links, correct?
        > Assuming that I haven't gotten really confused in all of this, then
        > I would think you'd want to send the max window on the OC-12 if it's RTT
        > was low (often a faster link even than your LAN on both ends).
        >
        > By stating it's a false positive, you make me think that you'd want slow
        > start in such a case- why?

        Yes, I phrased things badly there.

        My general claim is that it does not matter whether there is one hop or
        many, or whether some of the hops are longer or shorter. All that matters
        is that you want a go-fast mode that violates some of the proposed, even
        stronger language enforcing the TCP congestion control and avoidance
        mechanisms when there are sufficiently few, opportunites for congestion
        at the current instant. It would be nice if there the go-fast mode and
        how and when it is invoked were documented, for all of the standard reasons
        standards exist.

        I was trying to concede in those words that a fairly short, fast, but
        somewhat congested link can appear to have a very small RTT, when the RTT
        is measured with a single pair of packets, such as during the 3-way
        handshake.

        The point of a go-fast mode is the extreme case of what started the
        discussions in this mailing list (I think it was here) weeks or months
        ago about increasing the initial window for HTTP. If you have a
        semi-private 1 Gbit/sec link connecting hosts using 500KByte windows and
        1432 byte MSS to move blocks of data, you really do not want to wait for
        175 ACKs before you are using the full window. You use such large windows
        because your bandwidth*delay product is that large or larger, and you are
        going at speeds where much of the delay comes from inside your hosts.
        For example, if your operating system wakes up your application to dump
        to a screen buffer 10 or 20 ms, you want enough data on hand to make it
        worth while. Or consider moving files; most UNIX file systems do not
        deliver or sink GBytes/sec, but some do, and there soon will be more.
        Given today's cheap Gbit Ethernet and $2000 PC's with 100's of MByte of
        RAM, such scenarios are no longer found only among people with $30M CPU's,
        or at least with $B atomic particle detectors. Competative pressures will
        at least entice implementors to discard slow-start in such situations.
        If they are not conservative in how they turn off slow-start, their code
        will also turn it off in the classic cases where it is needed.


        Vernon Schryver vjs@...
      Your message has been successfully submitted and would be delivered to recipients shortly.