Bugzilla – Bug 1006
UDP socket tx buffer back pressure needed
Last modified: 2011-12-13 04:11:59 EST
Please see this post from Mathieu (and follow-ups), which I will cut/paste a snippet from below:
Both Packet and Udp sockets suffer from similar problems in ns-3: if
your application generates a lot of traffic without its own congestion
control, all of the packets generated will be dropped by the egress
NetDevice when its tx queue becomes full and the application has no way
of knowing when this happens. I would like to fix this (mostly because
the datagram sockets in ns-3-simu need this information to block the udp
traffic generation applications).
This is somewhat related to bug 141, which could easily be marked WONTFIX now but should definitely be closed when this bug is addressed.
I did exactly the same thing in a previous research project (modification was done in ns-3.4). The current ns-3 model is a "non-blocking" socket, which the send call will succeed anyway. But I think many real-world application expects a blocking socket, which does not return the call until the lower layer can really take the data.
Doing this will add a boolean m_blocking variable to ns3::Socket, so when m_blocking==false, the current code is run, but when m_blocking==true, we need to return immediately doing nothing for the Send call and invoke a callback when the socket becomes available again.
Let me take up this as an enhancement, but since it is near code freeze time, I will wait until the release to commit the code.
I fear that the solution is not that simple.
In a non-blocking system the time do advance between pre-tx and post-tx, as the tx is blocking. It implies that there is a time lapse *inside* the calling function.
In an event-driven simulation this implies that the application's Tx function is sort-of split in two:
1) pre-tx-call, executed at the intended time, and
2) post-tx-call, executed when the lower layer is "ready to accept data". basically a callback.
Adding a status in the Socket is the basis, but we need to handle the time-lapse as well, or any time-related feature will be screwed.
Example: an app sending a packet 10ms **after** the previous one has been sent. With blocking send the packets will be not isochronous, and that's what we'd like. If we don't handle the point above, they'll be still isochronous.
Mind, I'm totally up to support this feature, I'm just pointing out that it's not that simple to support it.