Hi again Andi,
After a talk with someone better versed in TCP than I am I think I
have a clearer understanding now of both your question and your packet
trace.
The client doesn't ask for retransmission beginning at 114229 because
with its "ACK 137589" it is acknowledging receipt of 114229-137588
already. You could say that the "ACK 114229" you were looking for is
implicit in "ACK 137589".
Vikki
=======================================================
On Wed, May 4, 2011 at 12:05 AM, Vikki Taxdal <vtaxdal@xxxxxxxxx> wrote:
> Hi Andi,
>
> You asked
>
> On Thu, Apr 28, 2011 at 4:19 AM, Andi Wijaya <stev2711@xxxxxxxxx> wrote:
>> My question is, packet no.193 is the Dup ACK and no.194 is the TCP retransmission,
>> but why no.195 does not do a TCP retransmission of 114229
>> (which is the next seq.) but go to 137589 (no 195)instead ?
>
> Frame 195 doesn't retransmit 114229 because 114229 was not lost; it
> arrived in frame 124.
>
> The TCP analysis flags are confusing when you first read them.
> Wireshark tells us at frame 124 that "TCP Previous segment was lost",
> but the previous segment is not 114229 but 112769 (111309 + 1460, from
> frame 123).
>
> If you display "ip.src == 10.10.1.58" and put tcp.seq and tcp.len in
> your columns you'll see that
> the client starts complaining about lost segments at frame 127,
> continuing up to193.
>
> And then when you display "ip.src == 125.252.232.170" you can see that
> the server sends the lost packets all at once (frames 194-216).
>
> Vikki
>
>
>
> =======================================================
> On Thu, Apr 28, 2011 at 4:52 PM, Andi Wijaya <stev2711@xxxxxxxxx> wrote:
>> Hi Guys,
>> I've uploaded the trace file in cloudshark for your reference.
>> My interest is what happen on packet no 193-196.
>> http://cloudshark.org/captures/bfc1d3359db2
>
> =======================================================
> On Thu, Apr 28, 2011 at 4:19 AM, Andi Wijaya <stev2711@xxxxxxxxx> wrote:
>> Hi Guys,
>> This is my first post, and it's so nice to be able to join this community so please excuse me if I make any mistake.
>> I'm doing a capture with SACK ON and with SACK OFF, my understanding is with SACK OFF, the server will have to retransmit the packet from the point of
>> packet lost. However what I see is the server does not retransmit the packet at all and just continuing with the rest of the data (please see the TCP
>> Trace screenshot attached). While for SACK ON, everything went well as the theory.
>>
>> SACK OFF: (I removed some column for easier viewing)
>> No Source Destination Seq.# Nxt.Seq. Ack.# Info
>> 193 10.10.1.58 125.252.232.170 2286 112769 [TCP Dup ACK 125#34] 1069 > 80 [ACK] Seq=2286 Ack=112769 Win=32768 Len=0
>> 194 125.252.232.170 10.10.1.58 112769 114229 2286 [TCP Retransmission] [TCP segment of a reassembled PDU]
>> 195 10.10.1.58 125.252.232.170 2286 137589 1069 > 80 [ACK] Seq=2286 Ack=137589 Win=32768 Len=0
>> 196 125.252.232.170 10.10.1.58 137589 139049 2286 [TCP Retransmission] Continuation or non-HTTP traffic
>> 197 10.10.1.58 125.252.232.170 2286 144889 1069 > 80 [ACK] Seq=2286 Ack=144889 Win=32768 Len=0
>>
>> My question is, packet no.193 is the Dup ACK and no.194 is the TCP retransmission, but why no.195 does not do a TCP retransmission of 114229
>> (which is the next seq.) but go to 137589 (no 195)instead ? Am I missing something here ? Thanks/
>