CS Personal on cloudshark.org

Packet	Last Edited	Note
1	pcapng	Client: Window Scaling, SACK and a decent MSS... so far, so good.
2	pcapng	Server: Window Scaling, SACK and a decent MSS. What could go wrong? Well... look at the delta time between the SYN packet and this SYN/ACK... yuck.
4	pcapng	Client: Ok - here's the request for the big fat file - the OpenOffice executable.
5	pcapng	Yup - we have a path latency issue here. Over 155ms roundtrip time between the GET and associated ACK. It's going to be a looooong day.
6	pcapng	So we know we have a high roundtrip path latency issue. If you disable TCP's "Allow subdissector to reassembly TCP streams," you can see the HTTP 200 Response Code in the Info column.
44	pcapng	At this point you might want to add a Calculated Window Size column to see how 10.0.52.164's receive buffer changes.
133	pcapng	Oh crap... packet loss. We expected Sequence Number 112750 before this one. This is Sequence Number 114210. Wireshark notices the issue and has marked the packet appropriately. We use SACK, so the recovery should be pretty smooth, right?
134	pcapng	This is the ACK that requests Seq No 112750 (see the ACK Num column). Expand the TCP header to examine the Options area - there's a SACK Left Edge (LE) and Right Edge (RE). Nice!
135	pcapng	It's going to take a while for the server to notice the Duplicate ACKs that are coming up. During that time, it continues to send data packets to the client.
136	pcapng	It's marked Dup ACK #1, but really this is the second identical ACK. The first one was packet 134 above. Remember that in "Fast Recovery," three identical ACKs should trigger a retransmission. Unfortunately, our Dupe ACKs are taking a slow boat to the server.
138	pcapng	Check out the SACK LE/RE value in the TCP Options area. Notice that this client is ACKing the data that is arriving while still complaining about the missing packet starting with Seq No 112750.
144	pcapng	This client is going to keep complaining that 112750 is missing until it gets that packet.
177	pcapng	Oh double crap. We've lost another packet. We never got the previous lost packet (Seq No 112750)! Now SACK gets interesting.
178	pcapng	Notice that this client now has two SACK LE/RE values. It can't change the ACK No field from 112750 until it receives that missing packet.
185	pcapng	Ouch, ouch, ouch! This is not fun!
215	pcapng	We got 112750! Fast, schmast! That wasn't fast! Well... OK... Wireshark is calling this a Fast Retransmission because it was triggered by the Fast Recovery process. In fact, Wireshark looks for Duplicate ACKs preceding a retransmission. What happens to the ACK No field in the client's next packet?
216	pcapng	Now the client is complaining about Seq No 136110. You can't alter the ACK No field value until you recover from each lost packet one at a time.
231	pcapng	Whew - looks like we're going to be able to get some work done today after all. This is the retransmission for the second packet lost in this trace file.
237	pcapng	Finally... the third missing packet has arrived. Seq No 149250. No more Dupe ACKs or Retransmissions are expected, right?