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

slow-start bit

Expand Messages
  • Sam Manthorpe
    Hi, Is there any reason why it wouldn t be a good idea to use one of the free bits in the TCP header as a `slow-start bit to enable a sender to indicate to
    Message 1 of 19 , May 14, 1999
    • 0 Attachment
      Hi,

      Is there any reason why it wouldn't be a good idea to use one of the
      free bits in the TCP header as a `slow-start' bit to enable a sender
      to indicate to the receiver that it is sending the first packet
      of a slow-start phase? This would enable the receiver to ACK
      immediately rather than delay the ACK, which can cause an unnecessary
      200ms delay in some scenarios.

      Thanks,
      Sam.

      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@...
    • David S. Miller
      From: sm@bossette.engr.sgi.com (Sam Manthorpe) Date: Fri, 14 May 1999 21:15:33 -0700 (PDT) Is there any reason why it wouldn t be a good idea to use one of the
      Message 2 of 19 , May 15, 1999
      • 0 Attachment
        From: sm@... (Sam Manthorpe)
        Date: Fri, 14 May 1999 21:15:33 -0700 (PDT)

        Is there any reason why it wouldn't be a good idea to use one of
        the free bits in the TCP header as a `slow-start' bit to enable a
        sender to indicate to the receiver that it is sending the first
        packet of a slow-start phase?

        I would first want to test to see if other implementations will not
        have interoperability problems. The bits are marked as reserved now,
        but who knows what some TCP stack in a printer will do if they are not
        zero.

        Later,
        David S. Miller
        davem@...
      • Eric A. Hall
        ... I read this as what are the mechanisms for doing circuit-setup messages with TCP, and is it a good idea? Right now, the only circuit-setup message we
        Message 3 of 19 , May 15, 1999
        • 0 Attachment
          > Is there any reason why it wouldn't be a good idea to use one of the
          > free bits in the TCP header as a `slow-start' bit to enable a sender
          > to indicate to the receiver that it is sending the first packet
          > of a slow-start phase?

          I read this as "what are the mechanisms for doing circuit-setup messages
          with TCP, and is it a good idea?" Right now, the only circuit-setup
          message we have is the MSS option. I suppose that it would be possible
          to add a flag that indicated that slow start was in effect, but why stop
          there? Shouldn't we also add flags for congestion avoidance, current
          retransmission timer, and so forth? All of these things will affect the
          bi-directional exchange of data in some manner.

          One could define a set of bits or options that passed this info back and
          forth. This would let the sender say "I'm at multiple four with slow
          start" and "my retransmission timer is currently set to 28 ms" for
          example. Or, going even further, it would be possible for one end-point
          to request certain values from the other end-point, like "please use
          28ms". It's early on a saturday morning and I'm just going through mail
          so I can't really think of a situation where that would be useful, but
          if it needs to be advertised then it can probably benefit from being set
          as well. Probably.

          There are lots of issues here of course. First and foremost is legacy
          support, which is the big thorn for all new options. It would take a
          really long time to update all of the existing products to use any new
          data in the header. Another issue is that lots of products out there
          don't do slow start, so passing the data would be irrelevant.

          I guess my feeling is that the broader issue of circuit-negotiation
          should definitely be addressed, but that it is sufficiently complex that
          it should probably be tabled for TCPng whenever that gets started. Would
          it make life easier or harder, and who would be affected by these
          messages (developers? users? admins?).

          I also think its time to start the work on TCPng.

          --
          Eric A. Hall ehall@...
          +1-650-685-0557 http://www.ehsco.com
        • Kevin Fall
          ... RFC2481 deals with this to some extent. Basically, a sender can indicate it has reacted to congestion in some way. This is useful in the scenario where
          Message 4 of 19 , May 15, 1999
          • 0 Attachment
            >
            > From: "Eric A. Hall" <ehall@...>
            > To: Sam Manthorpe <sm@...>
            > cc: tcp-impl@...
            > Subject: Re: slow-start bit
            > Date: Sat, 15 May 1999 09:29:47 PDT
            >
            >
            > > Is there any reason why it wouldn't be a good idea to use one of the
            > > free bits in the TCP header as a `slow-start' bit to enable a sender
            > > to indicate to the receiver that it is sending the first packet
            > > of a slow-start phase?
            >
            > I read this as "what are the mechanisms for doing circuit-setup messages
            > with TCP, and is it a good idea?" Right now, the only circuit-setup
            > message we have is the MSS option. I suppose that it would be possible
            > to add a flag that indicated that slow start was in effect, but why stop
            > there? Shouldn't we also add flags for congestion avoidance, current
            > retransmission timer, and so forth? All of these things will affect the
            > bi-directional exchange of data in some manner.
            >
            > One could define a set of bits or options that passed this info back and
            > forth.

            RFC2481 deals with this to some extent. Basically, a sender can
            indicate it has "reacted to congestion" in some way. This is useful
            in the scenario where a forward-traveling packet experiences ECN,
            the receiver needs to reflect this fact back in an ACK but the ACK
            may get lost, meaning the receiver actually echoes it back in each
            ack until it sees the sender's "reacted to congestion" bit.
            {thats the idea in a nutshell anyhow}.

            - K
          • John Hanley
            You propose modifying sender behavior so that cooperating receivers could improve throughput. Could we achieve the same thing purely within the receiver?
            Message 5 of 19 , May 15, 1999
            • 0 Attachment
              You propose modifying sender behavior so that cooperating receivers
              could improve throughput. Could we achieve the same thing purely within
              the receiver?

              Going to one end of the spectrum, we might grumble "delayed ACK increases
              the complexity of TCP dynamics and sometimes Does The Wrong Thing," and so
              we modify the receiver to never delay ACK. OK, clearly not what we want;
              under some conditions delayed ACK is winning.

              So let's think about those conditions: low packet loss, high throughput,
              typically corresponds to LAN latencies or at least large open window.
              How about just causing the receiver to never delay ACK if more than
              `threshold' time has elapsed since the last ACK sent by the receiver?
              Certainly `threshold' would be < 200ms; I'm thinking around 100ms or 50ms.
              If it is much less than sender's RTO interval, then receiver would effectively
              suppress delayed ACK *without* the sender signaling that in an option bit.


              Cheers,
              JH
            • Sam Manthorpe
              ... I m not sure. It would certainly be desirable but I haven t been able to think of a _simple_ way of doing it and that is an important criteria for me. ...
              Message 6 of 19 , May 15, 1999
              • 0 Attachment
                John Hanley wrote:
                >
                > You propose modifying sender behavior so that cooperating receivers
                > could improve throughput. Could we achieve the same thing purely within
                > the receiver?

                I'm not sure. It would certainly be desirable but I haven't been able
                to think of a _simple_ way of doing it and that is an important criteria
                for me.

                > So let's think about those conditions: low packet loss, high throughput,
                > typically corresponds to LAN latencies or at least large open window.
                > How about just causing the receiver to never delay ACK if more than
                > `threshold' time has elapsed since the last ACK sent by the receiver?
                > Certainly `threshold' would be < 200ms; I'm thinking around 100ms or 50ms.

                Wouldn't this be bad for slow, high latency connections? This would
                effectively switch off delayed-ack altogether since it wouldn't be
                too hard to have a connection where the inter-packet-arrival time at
                the receiver is greater than 50ms.

                > If it is much less than sender's RTO interval, then receiver would effectively
                > suppress delayed ACK *without* the sender signaling that in an option bit.

                How can the receiver know the sender's RTO? It could estimate it, but I
                can't think of any simple mechanism that would give a reliable enough
                estimate. Time between acking byte x and receiving byte x+1 wouldn't
                work because the receiver can't be sure that the sender's congestion
                window is such that sending byte x+1 requires byte x being acked.

                I would want to avoid any excessive complexity in the TCP stack since
                this is bad for low network latency, high bandwidth situations where
                performance is CPU and memory-access speed bound.

                The simplicity of the `slow-start-bit' appeals to me. I don't know
                how big of an issue the implementations using the reserved bits that
                David brough up is. This would also be an issue for ECN then.

                Cheers,
                Sam.

                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@...
              • Sam Manthorpe
                ... This is impossible to thoroughly test prior to software release, isn t it. I would introduce a systuneable to enable/disable the feature, default on, so
                Message 7 of 19 , May 15, 1999
                • 0 Attachment
                  David S. Miller wrote:
                  >
                  > From: sm@... (Sam Manthorpe)
                  > Date: Fri, 14 May 1999 21:15:33 -0700 (PDT)
                  >
                  > Is there any reason why it wouldn't be a good idea to use one of
                  > the free bits in the TCP header as a `slow-start' bit to enable a
                  > sender to indicate to the receiver that it is sending the first
                  > packet of a slow-start phase?
                  >
                  > I would first want to test to see if other implementations will not
                  > have interoperability problems. The bits are marked as reserved now,
                  > but who knows what some TCP stack in a printer will do if they are not
                  > zero.

                  This is impossible to thoroughly test prior to software release, isn't it.
                  I would introduce a systuneable to enable/disable the feature,
                  default on, so you could switch it off if your LAN has hosts with
                  broken stacks.

                  This would also be an issue for RFC 2481.

                  Cheers,
                  Sam.

                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@...
                • Jamal Hadi Salim
                  ... ECN (RFC2481), for example, tests by setting two of the bits during the SYN exchange. If the remote end responds with the same bit set then it is highly
                  Message 8 of 19 , May 15, 1999
                  • 0 Attachment
                    On Sat, 15 May 1999, David S. Miller wrote:

                    >
                    > I would first want to test to see if other implementations will not
                    > have interoperability problems. The bits are marked as reserved now,
                    > but who knows what some TCP stack in a printer will do if they are not
                    > zero.
                    >

                    ECN (RFC2481), for example, tests by setting two of the bits during the
                    SYN exchange. If the remote end responds with the same bit set then it is
                    highly likely that it is lying. You can use a combination of such tricks.
                    In the established state, it would be very tricky to catch
                    any misuse of the reserved bits.

                    cheers,
                    jamal

                    Computing Technology Labs (CTL), Nortel
                  • Spencer Dawkins
                    The I-D http://search.ietf.org/internet-drafts/draft-montenegro-pilc-ltn-01.txt (soon to be 02, but hasn t made it onto the web site yet) talks about some
                    Message 9 of 19 , May 15, 1999
                    • 0 Attachment
                      The I-D
                      http://search.ietf.org/internet-drafts/draft-montenegro-pilc-ltn-01.txt
                      (soon to be 02, but hasn't made it onto the web site yet) talks about some
                      aspects of larger initial windows and ACK-first/ACK-every strategies in
                      4.3.1 and 4.3.2. The target environment for this draft isn't just HTTP, but
                      we were thinking about HTTP, and it bothered us that the default was to do a
                      delayed-ACK timeout at the server if the HTTP request is bigger than a
                      single segment, followed by a delayed-ACK timeout at the client if the HTTP
                      response is bigger than a single segment - as it almost certainly would be.

                      We were pretty sure that ACK-first was safe, because it doesn't increase the
                      traffic level on the network (you send the ACK immediately instead of
                      delaying it, but it's the same ACK).

                      This draft is being discussed in the PILC working group (although it won't
                      be a WG output), but we would love to hear your thoughts as well.

                      Spencer

                      > -----Original Message-----
                      > From: David S. Miller [SMTP:davem@...]
                      > Sent: Saturday, May 15, 1999 7:26 AM
                      > To: sm@...
                      > Cc: tcp-impl@...
                      > Subject: Re: slow-start bit
                      >
                      > From: sm@... (Sam Manthorpe)
                      > Date: Fri, 14 May 1999 21:15:33 -0700 (PDT)
                      >
                      > Is there any reason why it wouldn't be a good idea to use one of
                      > the free bits in the TCP header as a `slow-start' bit to enable a
                      > sender to indicate to the receiver that it is sending the first
                      > packet of a slow-start phase?
                      >
                      > I would first want to test to see if other implementations will not
                      > have interoperability problems. The bits are marked as reserved now,
                      > but who knows what some TCP stack in a printer will do if they are not
                      > zero.
                      >
                      > Later,
                      > David S. Miller
                      > davem@...
                    • Neal Cardwell
                      On a related note, delayed ACKs can hurt performance even after the first few RTTs of slow start. Whether in congestion avoidance or slow start, a sender that
                      Message 10 of 19 , May 16, 1999
                      • 0 Attachment
                        On a related note, delayed ACKs can hurt performance even after the first
                        few RTTs of slow start. Whether in congestion avoidance or slow start, a
                        sender that uses any Vegas-like bandwidth estimation scheme incoporating
                        delay as a congestion signal will work much better if either
                        o the receiver does not delay ACKs
                        o the receiver tells the sender (with, say, a TCP option) by how much an
                        ACK was delayed

                        Currently, Vegas and other bandwidth estimation schemes are forced to jump
                        through hoops to filter out the effect of delayed ACKs because they
                        introduce delays that look similar to queuing delay.

                        neal
                      • Jamshid Mahdavi
                        ... Note that RFC2414 allows 2, 3, or 4 packets on initial slowstart, which alleviates the specific problem you are concerned with. Some of the other concerns
                        Message 11 of 19 , May 17, 1999
                        • 0 Attachment
                          sm@... (Sam Manthorpe) writes:

                          > Hi,
                          >
                          > Is there any reason why it wouldn't be a good idea to use one of the
                          > free bits in the TCP header as a `slow-start' bit to enable a sender
                          > to indicate to the receiver that it is sending the first packet
                          > of a slow-start phase? This would enable the receiver to ACK
                          > immediately rather than delay the ACK, which can cause an unnecessary
                          > 200ms delay in some scenarios.

                          Note that RFC2414 allows 2, 3, or 4 packets on initial slowstart,
                          which alleviates the specific problem you are concerned with. Some of
                          the other concerns which people brought up might still be interesting
                          to consider. The increased initial window doesn't apply after a
                          timeout, but generally you've already been waiting for ~ 1 sec on a
                          timeout anyway, so saving the 200 msec in that case may not be as
                          important to you.

                          --J
                        • David Borman
                          John, ... Many years ago I put the slow-start code into UNICOS. The poor interaction between the initial packet during slow-start and the delayed ACK/ACK
                          Message 12 of 19 , May 17, 1999
                          • 0 Attachment
                            John,

                            > Subject: Re: slow-start bit
                            > Date: Sat, 15 May 1999 11:05:38 -0700
                            > From: John Hanley <jh@...>
                            > ...
                            > How about just causing the receiver to never delay ACK if more than
                            > `threshold' time has elapsed since the last ACK sent by the receiver?
                            > Certainly `threshold' would be < 200ms; I'm thinking around 100ms or 50ms.
                            > If it is much less than sender's RTO interval, then receiver would effectively
                            > suppress delayed ACK *without* the sender signaling that in an option bit.

                            Many years ago I put the slow-start code into UNICOS. The poor
                            interaction between the initial packet during slow-start and the
                            delayed ACK/ACK every other packet stratagey became quite obvious,
                            both at connection startup and after the connection had been idle
                            for awhile and the sender restarted slow-start. There are two ways
                            to address this. Either the receiver doesn't delay ACKs during
                            slow-start, or the sender sends more than 1 packet to get past the
                            ack every other packet strategy.

                            I figured that I couldn't change all the other TCPs out there, and
                            since either one will improve throughput, I implemented the reciever
                            changes. When a connection was first opened, I immediatly acked the
                            first N packets (actually, first N*maxseg bytes) , and then went back
                            to the ack-every-other-packet strategy. I chose N=8 for no particular
                            reason, other than it was a power of 2, and 16 seemed too big. I didn't
                            just use N=2, because it helps to get through slow-start when you ACK
                            every packet, and with N=8 you can get through a couple of round-trip
                            times before going back to ack-every-other-packet. It worked fine, so
                            there never was any reason to change it.

                            The actual implementation took IRS and added N*maxseg to it. As long
                            as data arrived with a seq number less than that, it was immediatly
                            acked. Once we passed that point, the pointer was pulled along
                            equal to seg.rcv_next. Then, in TCP input, if the idle counter
                            got large enough to kick in slow-start, I reset the value to
                            seg.rcv_next + N*maxseg, so that packets would be immediatly ACKed
                            again.

                            The nice thing was that with these changes our throughput improved
                            both in Cray->Cray transfers, and other->Cray transfers.

                            Combine those receiver changes with the new initial window of 4K,
                            (see RFC 2414), and you can eliminate a lot of the artificial
                            delays due to bad delayed ACK interaction.

                            I don't see a need for a "slow start" bit. Effectivly it would be
                            a "please ACK immediatly" bit, and would be ripe for abuse by
                            setting it in every packet, in which case you'd have to put in code
                            to determine whether or not the bit is legitimate, which by the
                            way would be similar code to what I've just described, so just
                            skip the bit.

                            -David Borman, dab@...
                          • Rick Jones
                            ... I ve seen evidence that perhap sLinux and HP-UX 11 will immediately ack at least the first segment received. I ve not looked for anything beyond that. rick
                            Message 13 of 19 , May 17, 1999
                            • 0 Attachment
                              > Just curious, besides UNICOS, have you put it into other stacks, like BSDI?
                              > I am wondering how common this is, and if it is a good idea for people to
                              > implement that.

                              I've seen evidence that perhap sLinux and HP-UX 11 will immediately ack
                              at least the first segment received. I've not looked for anything beyond
                              that.

                              rick jones

                              --
                              these opinions are mine, all mine; HP might not want them anyway... :)
                              feel free to email, or post, but please do not do both...
                              my email address is raj in the cup.hp.com domain...
                            • Rick Jones
                              ... I ve seen evidence that perhap sLinux and HP-UX 11 will immediately ack at least the first segment received. I ve not looked for anything beyond that. rick
                              Message 14 of 19 , May 17, 1999
                              • 0 Attachment
                                > Just curious, besides UNICOS, have you put it into other stacks, like BSDI?
                                > I am wondering how common this is, and if it is a good idea for people to
                                > implement that.

                                I've seen evidence that perhap sLinux and HP-UX 11 will immediately ack
                                at least the first segment received. I've not looked for anything beyond
                                that.

                                rick jones

                                --
                                these opinions are mine, all mine; HP might not want them anyway... :)
                                feel free to email, or post, but please do not do both...
                                my email address is raj in the cup.hp.com domain...

                                From Kacheong Poon <kacheong.poon@...> Mon May 17 14:36:16 1999
                                Return-Path: <owner-tcp-impl@...>
                                Delivered-To: ListSaver-of-tcp-impl@...
                                Received: (qmail 30943 invoked by uid 7770); 17 May 1999 21:36:16 -0000
                                Received: from lombok-fi.lerc.nasa.gov (139.88.112.33)
                                by vault.egroups.com with SMTP; 17 May 1999 21:36:16 -0000
                                Received: (from listserv@localhost)
                                by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA12780
                                for tcp-impl-outgoing; Mon, 17 May 1999 15:30:43 -0400 (EDT)
                                Received: from mercury.Sun.COM (fw01.lerc.nasa.gov [139.88.145.14])
                                by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA12772
                                for <tcp-impl@...>; Mon, 17 May 1999 15:30:41 -0400 (EDT)
                                Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
                                by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12916
                                for <tcp-impl@...>; Mon, 17 May 1999 12:30:39 -0700 (PDT)
                                Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114])
                                by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA21767
                                for <tcp-impl@...>; Mon, 17 May 1999 12:30:32 -0700 (PDT)
                                Received: from shield (shield [129.146.85.114])
                                by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id MAA05156
                                for <tcp-impl@...>; Mon, 17 May 1999 12:30:20 -0700 (PDT)
                                Date: Mon, 17 May 1999 12:30:20 -0700 (PDT)
                                From: Kacheong Poon <kacheong
                              • Rick Jones
                                ... I ve seen evidence that perhap sLinux and HP-UX 11 will immediately ack at least the first segment received. I ve not looked for anything beyond that. rick
                                Message 15 of 19 , May 17, 1999
                                • 0 Attachment
                                  > Just curious, besides UNICOS, have you put it into other stacks, like BSDI?
                                  > I am wondering how common this is, and if it is a good idea for people to
                                  > implement that.

                                  I've seen evidence that perhap sLinux and HP-UX 11 will immediately ack
                                  at least the first segment received. I've not looked for anything beyond
                                  that.

                                  rick jones

                                  --
                                  these opinions are mine, all mine; HP might not want them anyway... :)
                                  feel free to email, or post, but please do not do both...
                                  my email address is raj in the cup.hp.com domain...

                                  From Kacheong Poon <kacheong.poon@...> Mon May 17 14:36:16 1999
                                  Return-Path: <owner-tcp-impl@...>
                                  Delivered-To: ListSaver-of-tcp-impl@...
                                  Received: (qmail 30943 invoked by uid 7770); 17 May 1999 21:36:16 -0000
                                  Received: from lombok-fi.lerc.nasa.gov (139.88.112.33)
                                • David S. Miller
                                  Date: Mon, 17 May 1999 14:01:11 -0700 From: Rick Jones ... I ve seen evidence that perhap sLinux and HP-UX 11 will immediately ack at least
                                  Message 16 of 19 , May 17, 1999
                                  • 0 Attachment
                                    Date: Mon, 17 May 1999 14:01:11 -0700
                                    From: Rick Jones <raj@...>

                                    > Just curious, besides UNICOS, have you put it into other stacks,
                                    > like BSDI? I am wondering how common this is, and if it is a
                                    > good idea for people to implement that.

                                    I've seen evidence that perhap sLinux and HP-UX 11 will immediately
                                    ack at least the first segment received. I've not looked for
                                    anything beyond that.

                                    On Linux we implemented things this way because if hosts handle the
                                    initial congestion window values correctly (ie. don't advance it for
                                    the initial SYN, unfortunately almost all stacks do) this is quite
                                    desirable behavior.

                                    Later,
                                    David S. Miller
                                    davem@...
                                  • Kacheong Poon
                                    ... Oh, I was not just asking if TCP would ack the first segment. I think many stacks already did that. David changed UNICOS not to delay any ack for the
                                    Message 17 of 19 , May 17, 1999
                                    • 0 Attachment
                                      > I've seen evidence that perhap sLinux and HP-UX 11 will immediately
                                      > ack at least the first segment received. I've not looked for
                                      > anything beyond that.
                                      >
                                      > On Linux we implemented things this way because if hosts handle the
                                      > initial congestion window values correctly (ie. don't advance it for
                                      > the initial SYN, unfortunately almost all stacks do) this is quite
                                      > desirable behavior.

                                      Oh, I was not just asking if TCP would ack the first segment. I think many
                                      stacks already did that. David changed UNICOS not to delay any ack for the
                                      first N=8 segments. This I do not believe is quite common. Is it?

                                      K. Poon.
                                      kcpoon@...
                                    • David S. Miller
                                      Date: Mon, 17 May 1999 15:27:52 -0700 (PDT) From: Kacheong Poon ... Oh, I was not just asking if TCP would ack the first segment.
                                      Message 18 of 19 , May 17, 1999
                                      • 0 Attachment
                                        Date: Mon, 17 May 1999 15:27:52 -0700 (PDT)
                                        From: Kacheong Poon <kacheong.poon@...>

                                        > On Linux we implemented things this way because if hosts handle
                                        > the initial congestion window values correctly (ie. don't advance
                                        > it for the initial SYN, unfortunately almost all stacks do) this
                                        > is quite desirable behavior.

                                        Oh, I was not just asking if TCP would ack the first segment. I
                                        think many stacks already did that.

                                        I believe several also do not, to match up with the "SYN congestion
                                        window" bug.

                                        David changed UNICOS not to delay any ack for the first N=8
                                        segments. This I do not believe is quite common. Is it?

                                        This is not common as far as I am aware. Perhaps it is done to jack
                                        up the congestion window quickly over high speed links?

                                        Later,
                                        David S. Miller
                                        davem@...
                                      • Andi Kleen
                                        ... Linux 2.2 acks the first segment after slow start (this means at the beginning or when an ooo or old segment has been seen) -Andi -- This is like TV. I
                                        Message 19 of 19 , May 17, 1999
                                        • 0 Attachment
                                          On Tue, May 18, 1999 at 12:27:52AM +0200, Kacheong Poon wrote:
                                          > > I've seen evidence that perhap sLinux and HP-UX 11 will immediately
                                          > > ack at least the first segment received. I've not looked for
                                          > > anything beyond that.
                                          > >
                                          > > On Linux we implemented things this way because if hosts handle the
                                          > > initial congestion window values correctly (ie. don't advance it for
                                          > > the initial SYN, unfortunately almost all stacks do) this is quite
                                          > > desirable behavior.
                                          >
                                          > Oh, I was not just asking if TCP would ack the first segment. I think many
                                          > stacks already did that. David changed UNICOS not to delay any ack for the
                                          > first N=8 segments. This I do not believe is quite common. Is it?

                                          Linux 2.2 acks the first segment after slow start (this means at the beginning
                                          or when an ooo or old segment has been seen)


                                          -Andi
                                          --
                                          This is like TV. I don't like TV.
                                        Your message has been successfully submitted and would be delivered to recipients shortly.