seeing Slow Start in Wireshark - TCP-IP

This is a discussion on seeing Slow Start in Wireshark - TCP-IP ; I saw a trace file showing the TCP Slow Start process awhile back but have not been able to capture traffic in my lab which is just a few WIN XP PCs, switches, routers and Wireshark. The trace file was ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: seeing Slow Start in Wireshark

  1. seeing Slow Start in Wireshark


    I saw a trace file showing the TCP Slow Start process awhile back but
    have not been able to capture traffic in my lab which is just a few
    WIN XP PCs, switches, routers and Wireshark.

    The trace file was FTP and for the data transfer I first saw two
    packets with data being sent then the ACK reply, then three packets
    with data being sent then the ACK reply and so on up to 5 packets
    being sent and being ACKed. No packets were lost and the RTT was
    typically between 1-3 ms.

    I do not have any further details on the trace file or the actual
    trace file.

    When capturing in the my lab doing FTP (or HTTP) I can't seem to see
    this, what I always see is two packet being sent and ACKed then two
    more being sent and ACKed and so on. I so far have not been able to
    see the Slow Start process in a packet capture.

    I was thinking that typically Slow Start would only be seen on LFN or
    networks with higher latency but the RTT times are similar to what I
    see in my lab in the trace file showing Slow Start. I am also
    researching limits or settings specifying how long TCP will wait
    before it has to send a ACK.

    My question is should I be able to see the Slow Start pattern in every
    capture or while always used it is really only seen under certain
    conditions.

    I appreciate any comments or reading suggestions that can help me
    understand TCP and reviewing trace files better.

    Regards,
    PLunte

  2. Re: seeing Slow Start in Wireshark

    In article <30e0f506-7c29-4771-997d-f0ab3b7e4950@a22g2000hsc.googlegroups.com>,
    wrote:
    >
    >I saw a trace file showing the TCP Slow Start process awhile back but

    [..]
    >
    >I appreciate any comments or reading suggestions that can help me
    >understand TCP and reviewing trace files better.


    http://www.wiresharktraining.com/

    alan

  3. Re: seeing Slow Start in Wireshark

    On Apr 23, 1:22 pm, gmc93saf...@yahoo.com wrote:

    > The trace file was FTP and for the data transfer I first saw two
    > packets with data being sent then the ACK reply, then three packets
    > with data being sent then the ACK reply and so on up to 5 packets
    > being sent and being ACKed. No packets were lost and the RTT was
    > typically between 1-3 ms.


    This is unusual and probably resulted from a non-standard TCP stack.
    Overly-delayed ACKs can result in slow transmit pacing.

    > When capturing in the my lab doing FTP (or HTTP) I can't seem to see
    > this, what I always see is two packet being sent and ACKed then two
    > more being sent and ACKed and so on.


    This is more typical.

    > I so far have not been able to
    > see the Slow Start process in a packet capture.


    This problem with delaying your ACKs too much is that it may cause the
    other end to start very slowly. You are still seeing slow start, look
    at the transmit pacing.

    > My question is should I be able to see the Slow Start pattern in every
    > capture or while always used it is really only seen under certain
    > conditions.


    You should always see slow start, but you should also see ACKs coming
    back pretty rapidly to get the transmit speed up.

    DS

  4. Re: seeing Slow Start in Wireshark

    On Apr 23, 4:22 pm, gmc93saf...@yahoo.com wrote:
    > I saw a trace file showing the TCP Slow Start process awhile back but
    > have not been able to capture traffic in my lab which is just a few
    > WIN XP PCs, switches, routers and Wireshark.
    >
    > The trace file was FTP and for the data transfer I first saw two
    > packets with data being sent then the ACK reply, then three packets
    > with data being sent then the ACK reply and so on up to 5 packets
    > being sent and being ACKed. No packets were lost and the RTT was
    > typically between 1-3 ms.


    I agree with David. This is unusual. An ACK should be generated for
    every second MTU-sized segment (RFC 1122 4.2.3.2)

    > When capturing in the my lab doing FTP (or HTTP) I can't seem to see
    > this, what I always see is two packet being sent and ACKed then two
    > more being sent and ACKed and so on. I so far have not been able to
    > see the Slow Start process in a packet capture.


    It sounds like you're describing something like:
    packet 1: data
    packet 2: data
    packet 3: ack
    packet 4: data
    packet 5: data
    packet 6: ack

    It's not clear from you description that each ACK was an
    acknowledgement for the two data segments immediately preceeding it.
    Were they?

    > My question is should I be able to see the Slow Start pattern in every
    > capture or while always used it is really only seen under certain
    > conditions.


    Slow start always happens, but it can be tough to spot in action.
    Remember that slow start is all about finding the optimal amount of in-
    flight data. For a short path, that amount will be small. Slow start
    might find it instantly.

    > I appreciate any comments or reading suggestions that can help me
    > understand TCP and reviewing trace files better.


    I think we'd be more help you you posted the capture somewhere.

    /chris

  5. Re: seeing Slow Start in Wireshark

    Here is what I have for the trace file showing slow start.

    I am trying to understand under what conditions a transfer like this
    would be seen, I so far have not seen anything like this as I am
    beginning to learn protocol analysis.

    Regards,
    PLunte

    0 .43 .99 TCP ftp-data > act [SYN] Seq=0 Win=8192 Len=0
    0.001 .99 .43 TCP act > ftp-data [SYN, ACK] Seq=0 Ack=1 Win=8760
    Len=0
    0 .43 .99 TCP ftp-data > act [ACK] Seq=1 Ack=1 Win=8760 Len=0
    0.043 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=2921 Win=8760 Len=0
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=7301 Win=8760 Len=0
    0.003 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.001 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=13141 Win=8760 Len=0
    0.003 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=18981 Win=8760 Len=0
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=20441 Win=8760 Len=0
    0 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=29201 Win=8760 Len=0
    0.003 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    0.002 .43 .99 FTP-DATA FTP Data: 80 bytes
    0 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=33661 Win=8760 Len=0
    0.001 .43 .99 TCP ftp-data > act [FIN, ACK] Seq=33661 Ack=1 Win=8760
    Len=0
    0 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=33662 Win=8760 Len=0
    0.003 .99 .43 TCP act > ftp-data [FIN, ACK] Seq=1 Ack=33662 Win=8760
    Len=0
    0 .43 .99 TCP ftp-data > act [ACK] Seq=33662 Ack=2 Win=8760 Len=0

  6. Re: seeing Slow Start in Wireshark

    On May 2, 4:50*pm, gmc93saf...@yahoo.com wrote:
    > Here is what I have for the trace file showing slow start.


    Interesting. Where did this capture come from? What OS?
    Particularly the ".99" end is of interest.

    > I am trying to understand under what conditions a transfer like this
    > would be seen, I so far have not seen anything like this as I am
    > beginning to learn protocol analysis.


    I can't think of anything that would make this happen. The receiver
    is ignoring his requirement to ACK every other full sized segment, but
    is somehow ACK-ing the after 2, then 3, then 4 segments, etc...

    This isn't slow start: Slow start grows exponentially, and is the job
    of the sender, not the receiver.

    ...and this likely isn't a slow start-like coincidence caused by a
    combination of linear ramp-up by the sender with minimalis ACK
    behavior from the receiver because the timing is so tight. That
    receiver generates the ACK quickly after each batch of data segments,
    so the sender probably wasn't holding back after bursts of data.

    You said at the top of this thread that you "saw a trace file"
    demonstrating this behavior. Do you have the actual capture in pcap
    format, or just this text? When I previously asked you to "post the
    capture somewhere", I meant the binary (pcap or otherwise) format.

    /chris

  7. Re: seeing Slow Start in Wireshark

    gmc93safari@yahoo.com wrote:
    > Here is what I have for the trace file showing slow start.
    >
    > I am trying to understand under what conditions a transfer like this
    > would be seen, I so far have not seen anything like this as I am
    > beginning to learn protocol analysis.
    >
    > Regards,
    > PLunte
    >
    > 0 .43 .99 TCP ftp-data > act [SYN] Seq=0 Win=8192 Len=0
    > 0.001 .99 .43 TCP act > ftp-data [SYN, ACK] Seq=0 Ack=1 Win=8760
    > Len=0
    > 0 .43 .99 TCP ftp-data > act [ACK] Seq=1 Ack=1 Win=8760 Len=0
    > 0.043 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=2921 Win=8760 Len=0
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=7301 Win=8760 Len=0
    > 0.003 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.001 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=13141 Win=8760 Len=0
    > 0.003 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=18981 Win=8760 Len=0
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=20441 Win=8760 Len=0
    > 0 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=29201 Win=8760 Len=0
    > 0.003 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.001 .43 .99 FTP-DATA FTP Data: 1460 bytes
    > 0.002 .43 .99 FTP-DATA FTP Data: 80 bytes
    > 0 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=33661 Win=8760 Len=0
    > 0.001 .43 .99 TCP ftp-data > act [FIN, ACK] Seq=33661 Ack=1 Win=8760
    > Len=0
    > 0 .99 .43 TCP act > ftp-data [ACK] Seq=1 Ack=33662 Win=8760 Len=0
    > 0.003 .99 .43 TCP act > ftp-data [FIN, ACK] Seq=1 Ack=33662 Win=8760
    > Len=0
    > 0 .43 .99 TCP ftp-data > act [ACK] Seq=33662 Ack=2 Win=8760 Len=0


    The following is an excerpt from Internetworking with TCP/IP, Volume I,
    3rd. Edition, page 215, (Douglas E. Comer):

    Slow-Start (Additive) Recovery: Whenever starting traffic on a new
    connection or increasing traffic after a period of congestion, start the
    congestion window at the size of a single segment and increase the
    congestion window by one segment each time an acknowledgment arrives.

    The description matches the trace.

    Best Regards,
    News Reader

  8. Re: seeing Slow Start in Wireshark

    In article ,
    chris writes:
    > On May 2, 4:50*pm, gmc93saf...@yahoo.com wrote:
    >> Here is what I have for the trace file showing slow start.

    > Interesting. Where did this capture come from? What OS?
    > Particularly the ".99" end is of interest.
    >> I am trying to understand under what conditions a transfer like this
    >> would be seen, I so far have not seen anything like this as I am
    >> beginning to learn protocol analysis.

    > I can't think of anything that would make this happen. The receiver
    > is ignoring his requirement to ACK every other full sized segment, but
    > is somehow ACK-ing the after 2, then 3, then 4 segments, etc...


    The receiver may see bursts of 2, then 3, then 4 segments due to interrupt
    mitigation. If the OS is smart enough to not send ACKs for every other
    full sized segment when it has three or more segments in the receiver
    queue you would get this kind of behavior.

  9. Re: seeing Slow Start in Wireshark

    On May 2, 8:09*pm, News Reader wrote:
    > gmc93saf...@yahoo.com wrote:
    > > Here is what I have for the trace file showing slow start.

    >
    > > I am trying to understand under what conditions a transfer like this
    > > would be seen, I so far have not seen anything like this as I am
    > > beginning to learn protocol analysis.

    >
    > > Regards,
    > > PLunte

    >
    > > 0 *.43 * * .99 * * TCP * * ftp-data > act [SYN] Seq=0 Win=8192 Len=0
    > > 0.001 * * *.99 * * .43 * * TCP * * act > ftp-data [SYN, ACK] Seq=0 Ack=1 Win=8760
    > > Len=0
    > > 0 *.43 * * .99 * * TCP * * ftp-data > act [ACK] Seq=1 Ack=1 Win=8760 Len=0
    > > 0.043 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.99 * * .43 * * TCP * * act > ftp-data [ACK] Seq=1 Ack=2921 Win=8760 Len=0
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.001 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.99 * * .43 * * TCP * * act > ftp-data [ACK] Seq=1 Ack=7301 Win=8760 Len=0
    > > 0.003 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.001 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.001 * * *.99 * * .43 * * TCP * * act > ftp-data [ACK] Seq=1 Ack=13141 Win=8760 Len=0
    > > 0.003 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.001 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.99 * * .43 * * TCP * * act > ftp-data [ACK] Seq=1 Ack=18981 Win=8760 Len=0
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.001 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.001 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.99 * * .43 * * TCP * * act > ftp-data [ACK] Seq=1 Ack=20441 Win=8760 Len=0
    > > 0 *.99 * * .43 * * TCP * * act > ftp-data [ACK] Seq=1 Ack=29201 Win=8760 Len=0
    > > 0.003 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.001 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 1460 bytes
    > > 0.002 * * *.43 * * .99 * * FTP-DATA * * * *FTP Data: 80 bytes
    > > 0 *.99 * * .43 * * TCP * * act > ftp-data [ACK] Seq=1 Ack=33661 Win=8760 Len=0
    > > 0.001 * * *.43 * * .99 * * TCP * * ftp-data > act [FIN, ACK] Seq=33661 Ack=1 Win=8760
    > > Len=0
    > > 0 *.99 * * .43 * * TCP * * act > ftp-data [ACK] Seq=1 Ack=33662 Win=8760 Len=0
    > > 0.003 * * *.99 * * .43 * * TCP * * act > ftp-data [FIN, ACK] Seq=1 Ack=33662 Win=8760
    > > Len=0
    > > 0 *.43 * * .99 * * TCP * * ftp-data > act [ACK] Seq=33662 Ack=2 Win=8760 Len=0

    >
    > The following is an excerpt from Internetworking with TCP/IP, Volume I,
    > 3rd. Edition, page 215, (Douglas E. Comer):
    >
    > Slow-Start (Additive) Recovery: Whenever starting traffic on a new
    > connection or increasing traffic after a period of congestion, start the
    > congestion window at the size of a single segment and increase the
    > congestion window by one segment each time an acknowledgment arrives.
    >
    > The description matches the trace.


    The trace started off with two segments (so not a perfect match to
    that description, and indicative of a modern TCP), but that's not
    what's suprising about it. ...What's suprising about the trace and
    Comer's decription is that they both describe a linear increase in the
    congestion window at the beginning of the connection.

    Every TCP I've seen in action follows Stevens' description. From TCP/
    IP Illustrated vol I:

    "The sender starts by transmitting one segment and waiting for its
    ACK. When that ACK is received, the congestion window is increased
    from one to two, and two segments can be sent. When each of those two
    segments is acknowledged, the congestion window is increased to four."

    /chris


  10. Re: seeing Slow Start in Wireshark

    On May 2, 9:16*pm, f...@securityaudit.val.newsbank.net (Dick
    Wesseling) wrote:
    > In article ,
    > * * * * chris writes:
    >
    > > On May 2, 4:50*pm, gmc93saf...@yahoo.com wrote:
    > >> Here is what I have for the trace file showing slow start.

    > > Interesting. *Where did this capture come from? *What OS?
    > > Particularly the ".99" end is of interest.
    > >> I am trying to understand under what conditions a transfer like this
    > >> would be seen, I so far have not seen anything like this as I am
    > >> beginning to learn protocol analysis.

    > > I can't think of anything that would make this happen. *The receiver
    > > is ignoring his requirement to ACK every other full sized segment, but
    > > is somehow ACK-ing the after 2, then 3, then 4 segments, etc...

    >
    > The receiver may see bursts of 2, then 3, then 4 segments due to interrupt
    > mitigation. If the OS is smart enough to not send ACKs for every other
    > full sized segment when it has three or more segments in the receiver
    > queue you would get this kind of behavior.


    The timestamps suggest otherwise. There's over 10ms between ACKs
    there. Not likely to be 10ms between interrupts. And that would be
    some coincidence of interrupt timing: it wasn't just after 2, then 3,
    then 4. That sequence went up to 6, and only stopped because the file
    transfer ended.

    Do sufficiently smart (as you've described) TCPs exist? I've only
    ever noticed tight compliance with this particular 'SHOULD'.


    /chris

  11. Re: seeing Slow Start in Wireshark

    chris wrote:
    > Do sufficiently smart (as you've described) TCPs exist? I've only
    > ever noticed tight compliance with this particular 'SHOULD'.


    The TCP stacks in HP-UX 11/11i and Solaris, and probably anything else
    with a "Mentat" heritage (perhaps some versions of MacOS, maybe
    others) have ACK-avoidance heuristics in their receive path. These
    heuristics figure the sender's cwnd and use that when looking to
    calculate by how much they can avoid sending ACKs without nasty
    effects. They (UX and I presume Solaris at least) also have
    mechanisms in them to fall-back to ack-every-other when their guesses
    aren't quite right.

    The effect on CPU utilization can be quite profound. I suspect I have
    some past posts to netnews and/or other forums (eg the linux netdev
    mailing list) one could find via a search with netperf figures. It
    has also in the past been "helpful" in SPECweb benchmarks but not as
    dramatic as one sees in say netperf TCP_STREAM. In particular
    SPECweb96 and SPECweb99, and to a lesser extent SPECweb99_SSL. Based
    on what I do and don't know about SPECweb2005 it is probably also
    helpful for that benchmark's "support" workload. In the case of
    SPECweb benchmarks, what matters are the load generators/clients since
    those are the systems generating most of the ACKs.

    rick jones
    --
    web2.0 n, the dot.com reunion tour...
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  12. Re: seeing Slow Start in Wireshark

    Sorry no trace file and I do not know the OS or anything else about
    how the trace file was recorded, I was doing temp work and saw part of
    a class on TCP and this was shown as an example to TCP Slow Start but
    I only got a handout. Now 8 months later I am trying to learn more
    about protocol analysis and TCP.

    I thank everyone for there input I am reading RFCs, Stevens and other
    material so am trying to learn more.

    There was one comment on transmit pacing which I do not understand
    yet, if someone had a specific reference that could help.

    >This problem with delaying your ACKs too much is that it may cause the

    other end to start very slowly. You are still seeing slow start, look
    at the transmit pacing.

    Thank You
    PLunte

+ Reply to Thread