Confusing result when comparing with TCP-socket-base log and pcap analysis through wireshark in TCP fast retransmission

[Sangwook Bae]

Hello, 

While I test the TCP (especially, TCP uses NewReno as the congestion control logic), I am confused about the TCP fast retransmission.

As far as I know, whenever the sender gets 3 dup ACK, the sender immediately send the dropped packet. 

Through the log, I think that the sender try to send the dropped packet (or retransmit the dropped packet) right after the sender gets 3 dupACKs.

However, When I look into the pcap file, the sender retransmits the dropped packet after the sender gets lots of duplicated ACKs.

Here is the screenshot picture showing the mentioned problem.

The retransmission  occurred when the sender gets 73 DUP ACK.

Could you please explain the reason of this issues? 

Thanks, 

Sangwook

[Natale Patriciello]

On 31/08/16 at 06:46am, Sangwook Bae wrote:
[cut]

> Through the log, I think that the sender try to send the dropped packet (or
> retransmit the dropped packet) right after the sender gets 3 dupACKs.
> However, When I look into the pcap file, the sender retransmits the dropped
> packet after the sender gets lots of duplicated ACKs.

The ns-3 log are the truth in this case: as you've done, if you put a
NS_LOG statement just after the ACK receive, you can see that after
three dupack the retransmission is sent out (exactly what you've
observed).

Now, when you look at the PCAP, you should remember that the segment is
not written directly to the file in the TCP layer. It passes down and
down through layers; and the PCAP helper just write it before (or after) the packet has
left the node. This means that, for example, if you have 2 nodes (Sender
and Receiver) and you're looking to the PCAP of receiver, in the case
you've just sent out your 3rd dupack, you will continue to receive data
packets from the sender, because it needs time to arrive to the sender
and being processed. After all this processing, the retransmission will
reach the receiver after it has sent out many dupacks. Does that mean
that the TCP implementation does not retransmit after the 3rd dupack?
It's just a matter of perspective, where the absolute one is the TCP
sender log.

Closing the ring, as soon as the TCP module (as you've seen) receive the
3rd dupack, it sends the retransmission out.

Nat

[Sangwook Bae]

Thanks for the kind reply.

First of all, the above figure is pcap file which is captured in the sender side. That means (or I think), the sender should send the packet for the retransmission. However, according to the pcap file, it seems that the sender sends retransmission packet later (or after sending the other data packet).

That's why I was asking about the existence of queuing structure (TcpTxBuffer). If there is a queuing structure, the retransmitted packet should takes first places in the buffer for the fast retransmission.

Here is an example what I think.

The Tcp-socket-base decides to retransmit the dropped packet when it gets 3 dupack. Then, it calls SendDataPacket() function. However, the TCPTxBuffer already has (or contains) other packets to be sent. In that case, the retransmission packet will be queued at the end of the bufffer. Therefore, the retransmitted packet will wait to be sent. 

Right now, I didn't check how the TcpTxBuffer is implemented, so I need to check.

By the way, what I am trying to do was that, just implement the TCP sender and receiver, with limited bandwidth and link delay. Therefore, I limit the queue size (specifically, PfifoFastQueueDisc). However, It looks to slow to receive the data. So, I am checking the TcpSocket::SndBufSize, RcvBufsize as well, but it was not helpful. (I am currently using TCPNewReno as the congestion control algorithm)

Thank you.

Sangwook

[Natale Patriciello]

On 01/09/16 at 12:51am, Sangwook Bae wrote:
> First of all, the above figure is pcap file which is captured in the sender
> side. That means (or I think), the sender should send the packet for the
> retransmission. However, according to the pcap file, it seems that the
> sender sends retransmission packet later (or after sending the other data
> packet).

Read down... anyway, for later: the right answer is "or after sending
the other data packet" (which, in TCP notations, are segments)

> That's why I was asking about the existence of queuing structure
> (TcpTxBuffer). If there is a queuing structure, the retransmitted packet
> should takes first places in the buffer for the fast retransmission.

Ah! Wait. TcpTxBuffer queues data from application. When TCP sends data,
it is queued in the traffic control layer.

> Here is an example what I think.
> The Tcp-socket-base decides to retransmit the dropped packet when it gets 3
> dupack. Then, it calls SendDataPacket() function. However, the TCPTxBuffer
> already has (or contains) other packets to be sent. In that case, the
> retransmission packet will be queued at the end of the bufffer. Therefore,
> the retransmitted packet will wait to be sent.

s/TcpTxBuffer/[some qdisc in traffic control layer]/g , for the rest
that's ok, and that's how any operating system works, UNLESS it
implements some scheduling technique (retransmission packets have an
higher precedence)

> By the way, what I am trying to do was that, just implement the TCP sender
> and receiver, with limited bandwidth and link delay. Therefore, I limit the
> queue size (specifically, PfifoFastQueueDisc). However, It looks to slow to
> receive the data. So, I am checking the TcpSocket::SndBufSize, RcvBufsize
> as well, but it was not helpful. (I am currently using TCPNewReno as the
> congestion control algorithm)

Who is slow to receive data? Application ? If so, please consider the
retransmissions (as you're already doing), and the time that they need
to arrive correctly to the receiver (we currently don't support SACK,
but it can help a lot in your situation).

Nat

[Sangwook Bae]

Thanks a lot.

Right now, I am trying to do with NSC TCP and compare it with the NSTCP. 

I think SACK also affects to the slow transmission when the packets are lost.

Thanks

Sangwook