Time to live (TTL) expiration in point-to-point link

[Marco Giordani]

Hi all,

I am configuring a simple P2P channel between two nodes, with the purpose of evaluating the behavior of the TCP CW, throughput and RTT when considering a variable rate for the P2P link.

For instance, assume that the P2P link has a constant rate to 100Mbps. At a certain point, say at time t = 1.5s, I manually change the rate of the link to 1Kbps, before recovering the full rate (100Mbps) at time t =2s. 

Now, I expect that the TCP throughput will be very low during the time at which the rate has been manually decreased, and that it would increase again as soon as the original link capacity is restored. However, what I get is that the throughput will  be constantly zero (i.e., no more packets are correctly exchanged) for the whole remaining simulation time, due to a "Time to Live expiration" event, as I understand from analyzing the .pcap traces that have been generated throughout the simulation (see attached image):

This is quite unreasonable to me. In fact, the TTL field is decreased only when the packet is relayed from one hop to the other, while the considered point-to-point configuration should not be affected by this kind of routing issues.

Does anyone has an explanation for this strange behavior? 

Thanks for your support.

[Tommaso Pecorella]

Hi,

not really, but if you can attach the script we can give a look at the issue.

T.

[Marco Giordani]

Dear Tommaso, thanks for your answer. 

Please find attached the ns-3 script "tcp-test.cc" and the .txt file "rate_trace.txt" that I periodically parse during the simulation (through the method BandwidthTrace() ) to update the rate of the P2P link. 

Thanks for your time, 

Marco

[Manuel Requena]

Hi,

In this scenario, the ICMP seems Ok (but with a wrong Code). It should be Code 1 = fragment reassembly time exceeded (See RFC 792)

In your scenario, you set the TcpSocket::SegmentSize to 14000. This will generate IP fragments of 1500 bytes of your TCP segments.

Then you set the Ipv4L3Protocol::FragmentExpirationTimeout to 1 sec (the default value is 30secs) and when you reduce the rate of the p2p link,
I guess, this timeout is too short for your IP segments that are waiting in the fragments list to be reassembled.

Best regards,

Manuel

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+unsubscribe@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Marco Giordani]

Dear Manuel,

thanks for your reply. I've changed the "FragmentExpirationTimeout" to 30 seconds, and now the "TTL exceeded" packet is no longer generated.

Nevertheless, I still experience the same issue for the TCP throughput (see attached image):

The rate changes every second and, while at seconds 2 and 4 the rate is fully recovered after the link breakouts, at time t=5 the throughput becomes zero till time t=17 (even if the link recoverers its full rate at time t=6). Is this somehow reasonably explicable?

To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.

[Tommaso Pecorella]

Hi both,

I just pushed a fixed for the wrong ICMP opcode. Thanks for spotting it.

T.