TCP retransmission issue

400 views
Skip to first unread message

Vineet

unread,
Jul 15, 2015, 6:05:28 AM7/15/15
to ns-3-...@googlegroups.com
Hi,

I am using TCP new reno source in a congested network, and i seek to trace the lost and retransmitted packets. In my experiment, the payload of the TCP packet is 1 byte which makes the packet size 43 bytes. Now, the packet with sequence number = 89 gets lost at t = 1.056s. It is retransmitted at at t = 1.075s and successfully received at t = 1.093s. The length of the retransmitted packet is 120 bytes. In the intervening time (1.056 < t < 1.093), more packet are lost. But the pcap trace does not show the retransmission of these, since the receiver keeps sending packets with ACK = 89 till t = 1.093s. How are the other lost packets recovered, and what is the justification for the increased length of retransmitted packets?

Thanks in advance.

Nat P

unread,
Jul 15, 2015, 8:27:48 AM7/15/15
to ns-3-...@googlegroups.com


Il giorno mercoledì 15 luglio 2015 12:05:28 UTC+2, Vineet ha scritto:
Hi,

I am using TCP new reno source in a congested network, and i seek to trace the lost and retransmitted packets. In my experiment, the payload of the TCP packet is 1 byte which makes the packet size 43 bytes. Now, the packet with sequence number = 89 gets lost at t = 1.056s. It is retransmitted at at t = 1.075s and successfully received at t = 1.093s. The length of the retransmitted packet is 120 bytes. In the intervening time (1.056 < t < 1.093), more packet are lost. But the pcap trace does not show the retransmission of these, since the receiver keeps sending packets with ACK = 89 till t = 1.093s. How are the other lost packets recovered, and what is the justification for the increased length of retransmitted packets?

Hi,

from what I understand, this is the normal fast recover/fast retransmit algorithm.

Please, remember that TCP is a stream-based protocol, the notion of "packets" doesn't exists. This could help you to clarify what is happening on the network.

Nat

Vineet Gokhale

unread,
Jul 15, 2015, 8:39:28 AM7/15/15
to ns-3-...@googlegroups.com
Thanks for your response.

I spent a lot of time scratching my head over the reception of other lost packets whose ACKs are not sent. This is not the crux of my work. So for now, shall i assume that every byte is successfully received during the session? This might sound like a naive query, but its very critical for my interpretation of things.

Thanks in advance!


--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/nym-53SURVo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

Nat P

unread,
Jul 15, 2015, 8:47:45 AM7/15/15
to ns-3-...@googlegroups.com


Il giorno mercoledì 15 luglio 2015 14:39:28 UTC+2, Vineet ha scritto:
Thanks for your response.

I spent a lot of time scratching my head over the reception of other lost packets whose ACKs are not sent. This is not the crux of my work. So for now, shall i assume that every byte is successfully received during the session? This might sound like a naive query, but its very critical for my interpretation of things.

Your last ACK to what SEQ refers to ? If it refers to the last transmitted SEQ, all the bytes are ACKed successfully.

Nat

Vineet Gokhale

unread,
Jul 15, 2015, 9:08:16 AM7/15/15
to ns-3-...@googlegroups.com
For example, by the time seq no 89 is successfully retransmitted, seq nos 100, 103 and 120 are lost. After the successful reception of 89, the ack no points to 120. So is it implicit that 100 and 103 are successfully received?

--

Tommaso Pecorella

unread,
Jul 15, 2015, 10:06:07 AM7/15/15
to ns-3-...@googlegroups.com
Can I suggest to study the TCP RFCs ?
They are public, and studying them will save you a lot of time.

T.

Nat P

unread,
Jul 15, 2015, 11:11:58 AM7/15/15
to ns-3-...@googlegroups.com


Il giorno mercoledì 15 luglio 2015 15:08:16 UTC+2, Vineet ha scritto:
For example, by the time seq no 89 is successfully retransmitted, seq nos 100, 103 and 120 are lost. After the successful reception of 89, the ack no points to 120. So is it implicit that 100 and 103 are successfully received?

Yes, it is a basic concept of TCP. I suggest (along with Tommaso's comment) to read in particular:

- Duplicated ACKs
- Cumulative ACKs

Have a nice day

Nat
Reply all
Reply to author
Forward
0 new messages