seeing Slow Start in Wireshark
gmc93...@yahoo.com
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
Alan Strassberg
>
>I appreciate any comments or reading suggestions that can help me
>understand TCP and reviewing trace files better.
http://www.wiresharktraining.com/
alan
David Schwartz
> 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
chris
> 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
gmc93...@yahoo.com
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
chris
> 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
News Reader
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
Dick Wesseling
chris <google...@marget.com> 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.
chris
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
chris
Wesseling) wrote:
> In article <eb7c0c8c-a317-446f-9adf-4b4d16c3f...@p25g2000hsf.googlegroups.com>,
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
Rick Jones
> 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...
gmc93...@yahoo.com
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