Bug 2966 - TCP seems memory thirsty
TCP seems memory thirsty
Status: NEEDINFO
Product: ns-3
Classification: Unclassified
Component: tcp
pre-release
All All
: P3 enhancement
Assigned To: natale.patriciello
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-08-06 14:21 EDT by Chih-Yuan Chang
Modified: 2018-08-20 16:17 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chih-Yuan Chang 2018-08-06 14:21:56 EDT
Hi,

I have some simulations to test performance of a clusters of nodes (<280 nodes). 

My TcpTxBuffer & TcpRxBuffer are sized at 4MB each. The TCP RX buffer will always be cleaned up by my applications whenever the TCP notifies my application. My applications only send when TCP tells the application that it has enough TX buffer space. The total buffer in the WHOLE system simulated is ~1.6GB (size for packet sizes accounting). So there are theoretically at most ~1M packets (1.5KB each) in the system simultaneously.

As an example, in a simulation of ~180M packets over ~1.5seconds simulation time, the LSF summary said the peak memory usage is ~200GB. Since there are theoretically at most ~1M packets in the system simultaneously, I felt the memory consumption is way too much.

Please help in relieving this huge memory consumption problem.
Comment 1 Chih-Yuan Chang 2018-08-06 14:24:50 EDT
Some packets may be dropped in the system due to congestion, and cause re-transmission.
Comment 2 Chih-Yuan Chang 2018-08-06 14:27:43 EDT
The total TCP byte-in-flight (returned by TcpSocket ByteInFlight) at peak time is ~0.9GB for the WHOLE system.
Comment 3 Tom Henderson 2018-08-06 21:06:53 EDT
Is there a smaller scale test case program that you can share (post to this bug report) that demonstrates the problem?
Comment 4 natale.patriciello 2018-08-20 03:33:47 EDT
Without measurements, it is impossible to say that the cause is TCP. It may be a tag (packet or byte tag).

Anyway, for your use case, the use of ns-3 seems out of scope. The network stack is mainly for education purpose. You may want to consider the use of a real stack (DCE with Linux could be an option).


Status changes as a feature request.
Comment 5 Chih-Yuan Chang 2018-08-20 13:27:29 EDT
For each packet, 1 packet tag & 1 byte tag is added.
Would that be the problem?
Comment 6 natale.patriciello 2018-08-20 14:13:22 EDT
The Packet Tag will be lost at the first step (in the TCP code), but its metadata will remain in the packet, carrying in all the path a ghost tag.

The byte tag will be duplicated exponentially each time the TCP performs a split (imagine when you have a smaller segment size than the application packet) or a join (retransmitted packets, or merge cases).

Try to see what is the difference with and without using the tags (Packet and Byte) and report the result: that is an important benchmark.


Thank you
Comment 7 Chih-Yuan Chang 2018-08-20 14:55:47 EDT
Packet tag clarification: the packet tag is added under TCP layer. So the TCP TX end point won't see it at all.

Byte tag: my application layer needs the byte tag to work. 

But I did see the TCP splitting codes replicating the ByteTagList, etc. So I did experiment on the memory allocated for PacketTagList & ByteTagList (& Buffer & meta data). The "net" memory allocated are less then 1GB throughout the simulation. However, I do not know whether the memory returned by delete/free is properly managed. (The total amount of memory EVER allocated is hundreds of GB.)
Comment 8 natale.patriciello 2018-08-20 16:17:43 EDT
(In reply to Chih-Yuan Chang from comment #7)
> Packet tag clarification: the packet tag is added under TCP layer. So the
> TCP TX end point won't see it at all.
> 

OK, but the cost is still there for each packet (and the Metadata is propagated even when the tag is removed) 

> Byte tag: my application layer needs the byte tag to work. 

So it's badly crafted. You should try to avoid byte tags,put the information as payload under the firm of an header

> 
> But I did see the TCP splitting codes replicating the ByteTagList, etc. So I
> did experiment on the memory allocated for PacketTagList & ByteTagList (&
> Buffer & meta data). The "net" memory allocated are less then 1GB throughout
> the simulation. However, I do not know whether the memory returned by
> delete/free is properly managed. (The total amount of memory EVER allocated
> is hundreds of GB.)

Are you saying that without tags the memory consumption is inline to what theoretically we could expect?
Anyway, many tests on packets seems to confirm that there aren't leaks, and tcp does use the packet api to perform operations on the packets,nothing custom. 

Nat