Problem of RTT initialization in rtt-estimator

[Tianyuan Wang]

Hi all,

I was working on a simulation experiment of TCP with ns-3.23.

I found that rtt is initialized to Seconds(1.0) in RttEstimator, while in tcp-socket-base is 0.

 TypeId

44 RttEstimator::GetTypeId (void)

45 {

46  static TypeId tid = TypeId ("ns3::RttEstimator")

47  .SetParent<Object> ()

48  .SetGroupName ("Internet")

49  .AddAttribute ("InitialEstimation",

50  "Initial RTT estimate",

51  TimeValue (Seconds (1.0)),

52  MakeTimeAccessor (&RttEstimator::m_initialEstimatedRtt),

53  MakeTimeChecker ())

54  ;

55  return tid;

56 }

So, when i use rtt to do some calculations in NewAck(const SequenceNumber32& seq) , there is always a "1" in front of real estimated rtt.

Why initialize rtt to Seconds(1.0)? And is that necessary?

 

Thanks in advance,

Tianyuan

[Tommaso Pecorella]

Hi,

yes, it is necessary. This is the RTT used for the very first packets, i.e., the 3-way handshake and the ones immediately after. A lower value could lead to unnecessary retransmits and failures in connection.

Moreover, 1 sec is the Linux default value.

T.

[Tianyuan Wang]

T, thanks very much for your reply.

So can I assume that the first rtt I got in NewAck(seq), which is 1 sec, is because of a SYN was received?

Actually, I encountered an another strange phenomena while doing a simulation experiment of TCP-NewReno. I will be very appreciate if you can explain.

There are several RTOs when I run tcp-variants-comparision.cc with error_p = 0.008 over tcp-newreno.

I feel confused after checking the pcap-file.

It kept sending new packets instead of retransmiting immediately after receiving 3 dupACK. More than 5 dupACK was received before fast retransmition starts, which may be a reason of RTOs in my opinion.

Is that because fast retransmition must be called when all packages in cwnd are sent?

Attatchments are a cwnd-graph and a screenshot of the pcap-file.

Other parament setting as followed:

error_p = 0.008;

transport_prot = TcpNewReno;

bandwidth = 10Mbps;

access_bandwidth = 20Mbps;

mtu_bytes=1500;

num_flows = 1

Thank you in advance.

Tianyuan

在 2016年4月7日星期四 UTC+8下午3:52:27，Tommaso Pecorella写道：

[Nat P]

Hi, please redo the simulation with the lastest ns-3.25.

Thanks

[Tianyuan Wang]

Hi, Nat! Thank you for replying.

I redo it with ns-3.25 again. The number of RTOs does get less.

However, what I mentioned is the fast retransmission didn't start immediately after receiving 3 DupACK, which didn't get better with ns-3.25. And I wonder why.

1. In the screenshoot of pcap-file, before the fast retransmission starts, there are 6 DupACKs. That 

2. Moreover, the first ACK right after the fast retransmission didn't trigger an another retransmission. It waits almost 1 sec (at 11.675s - 12.637s).

Wish I have explained the phenomena clearly enough.

Attatchments are a cwnd-graph and a screenshot of the pcap-file.

Paraments setting as followed:

[Nat P]

Hi, I don't have a fast explanation on what's happening.  If you want to investigate, you can turn debug logging for tcpsocketbase on.

Anyway.. just guessing. Before this particular congestion case, everything is ok? Or do you have other losses ? Because, for example, if you have other fast retransmission, the RTO timer is reset only for the first partial ACK (as RFC says). So maybe the thing that wireshark mark as " Fast Retrnamission" is in reality a retranmission for RTO (just guessing, eh). The log however should explain all in

[Tianyuan Wang]

Hi, Nat. Thank you for the suggestion. 

I turned on the log and found out that before the RTO, there are several dupACKs which can't reset the RTO timer as you said.

Besides, I found that the recorded seqs of retransmited segment aren't the same between pcap-file and log-file, differing 1440(a packet).

I'm not sure whether that matters or not. Just let you know in case.

The log-file as followed with a screenshot of pacp-file attachment.

 [node 1] Received (scaled) window is 2097152 bytes
 [node 1] 11.7083 ACK of 3519361 SND.UNA=3519361 SND.NXT=3530881
 [node 1] 5 Dupack received in fast recovery mode.Increase cwnd to 10800
 [node 1] UnAckCount=11520, Win=10800
 [node 1] 1 Got timestamp=11691 and Echo=11594
 [node 1] Received (scaled) window is 2097152 bytes
 [node 1] 11.7095 ACK of 3519361 SND.UNA=3519361 SND.NXT=3530881
 [node 1] 6 Dupack received in fast recovery mode.Increase cwnd to 12240
 [node 1] UnAckCount=11520, Win=12240
 [node 1] RTO. Reset cwnd to 1440, ssthresh to 2880, restart from seqnum 3519361
 [node 1] 1 Add option TS, ts=12636 echo=11691
 [node 1] 12.6361 Send segment of size 1440 with remaining data 2095200 via TcpL4Protocol to 10.0.2.2. Header 49153 > 50000 [ACK] Seq=3519361 Ack=1 Win=32768 ns3::TcpOptionTS(12636;11691)

Thanks again:).

Tianyuan

在 2016年4月8日星期五 UTC+8下午11:25:37，Nat P写道：

[Nat P]

Il giorno lunedì 11 aprile 2016 16:46:25 UTC+2, Tianyuan Wang ha scritto:

Besides, I found that the recorded seqs of retransmited segment aren't the same between pcap-file and log-file, differing 1440(a packet).

I'm not sure whether that matters or not. Just let you know in case.

The log-file as followed with a screenshot of pacp-file attachment.

It's only a different view of presenting things; in code, we should print the sequence number of the packet (that is what you see in wireshark - the size). So, the value are the same, or in particular, ns-3 is more careful in what it prints :)

Na

[Tianyuan Wang]

It's very kind of you to explain all that for me.

Thanks a lot :) !

Tianyuan

在 2016年4月11日星期一 UTC+8下午11:57:31，Nat P写道：

[Nat P]

Il giorno martedì 12 aprile 2016 05:16:12 UTC+2, Tianyuan Wang ha scritto:

It's very kind of you to explain all that for me.

Thanks a lot :) !

A well-done question always deserve the proper attention :)

You're welcome

Nat