Xing Xu
Mar 5, 2016, 12:37:18 PM3/5/16
to ns-3-users
Dear all,
I'm using LENA and in my scenario, the TCP flow between remote host and UE does not work as I expected. The scenario is only one direction: remote host is sending data to UE (bulk sender) but UE will not send data on uplink.
As I only have remote host end .pcap trace, I can only figure out problems from there. I found that there are lots of duplicated ACKs that limits sending rate, which is due to packet loss I guess. But if I use FlowMonitor to monitor this flow, I don't see any packet loss there. Then I don't know what's the issue, are there network layer packet losses? Or are there some other reasons for this duplicated ACKs?
So, first, are there other methods to monitor UE end pcap trace? I know it's not possible to get pcap.
Right now I'm only using FlowMonitor, how to understand FlowMonitor results?
# of sending packets is what remote host send in that period?
# of received packets is what UE received in that period?
and packet loss is what base station sent but have not been received by UE?
(If you think those questions can be answered by document, please refer me to that too).
Assume there is packet loss, another question is, bufferbloat is a well known observation for cellular network, where base stations will do aggressive link layer retransmission and thus there is no network layer packet loss. Is that the case for NS3-LENA? If it's not, is this easy to implement in NS3? Or, can I configure to hide network layer packet loss?
W/ or w/o packet loss, I suspect the problem is due to uplink ACK which limits the sending rate (I said "limits" because by using UDP I can achieve much higher downlink throughput), so I have question to uplink too. What is the scheduler for base station uplink? How does that work? Which file should I look at?
I have asked lots of questions, they are different potential solutions for my goal. Thanks in advance!
Xing Xu
Mar 5, 2016, 1:11:29 PM3/5/16
to ns-3-users
Another question, will base station drop packets if it sees packets queue for one UE is too long (which automatically leads to packet loss)?
Tommaso Pecorella
Mar 5, 2016, 6:41:59 PM3/5/16
to ns-3-users
Hi,
I can only answer partially, because for the other question I don't know the answer.
Network level packet losses are unlikely, LTE is very robust against losses (like Wi-Fi). They'll drop the bit rate before loosing packets, or just after loosing one.
The jitter could be a problem tho. DupAcks could be triggered by RTT variation.
FlowMonitor: yes, yes and packet lost are the packets that have been reported as explicitly dropped or that have not been seen transmitted or received in 10 seconds. Due to this 10 seconds delay, it is a good idea to stop the sources at least 10 seconds before the simulation ends. Otherwise the packet lost counter is a best guess.
Moreover, mind that the forwarded counter is affected by packet fragmentation, and there's no real way to fix this.
Cheers,
T.
Xing Xu
Mar 6, 2016, 12:08:12 AM3/6/16
to ns-3-users
Thanks for your quick response!
What do you mean by RTT variation can trigger DupAcks? I don't get it, isn't it triggered by missing a previous packet while received a new one (so, packet loss or re-order)?
And, based on your answer, seems that FlowMonitor reports L3 packet loss, right? Which is either dropped by base station or failed to deliver to UE (assume 10s is not a problem)? Can I disable this packet dropping at base station, or at least enlarge the queue length (because I feel that is the key to generate bufferbloat phenomena)?
Tommaso Pecorella
Mar 6, 2016, 5:32:01 AM3/6/16
to ns-3-users
Hi,
about DupAck you could be right, but I'd need some time to think about it. However, I forgot to mention one thing. There are a number of TCP things that have been fixed and changed in the recent -dev branch (that will become 3.25 soon).
I hope you're using ns-3-dev, as your mileage may vary greatly.
About the Ebb queues, I think they're finite (hence, possibly causing bufferbloat), but I never checked their size. It shouldn't be hard to find tho... search for them.
Cheers,
T.
Nat P
Mar 6, 2016, 9:42:40 AM3/6/16
to ns-3-users
Il giorno domenica 6 marzo 2016 00:41:59 UTC+1, Tommaso Pecorella ha scritto:
Network level packet losses are unlikely, LTE is very robust against losses (like Wi-Fi). They'll drop the bit rate before loosing packets, or just after loosing one.The jitter could be a problem tho. DupAcks could be triggered by RTT variation.
Uhm, it depends. Well, it depends on the parameters; I'm betting he is using default parameters. Xing, I suggest to check buffer sizes along the path, especially if using LTE unack mode.
Nat
Xing Xu
Mar 6, 2016, 7:15:59 PM3/6/16
to ns-3-users
I will try AM, I think that would be more realistic for current cellular networks, where we see bufferbloat.
But, I still want to know how to check buffer sizes, can you give me instructions on that? (I'm pretty new to NS3, thanks.)
Nat P
Mar 7, 2016, 3:31:48 AM3/7/16
to ns-3-users
Il giorno lunedì 7 marzo 2016 01:15:59 UTC+1, Xing Xu ha scritto:
I will try AM, I think that would be more realistic for current cellular networks, where we see bufferbloat.But, I still want to know how to check buffer sizes, can you give me instructions on that? (I'm pretty new to NS3, thanks.)
Since you are new, you are (partially) excused: check the LENA documentation (https://www.nsnam.org/docs/release/3.24/models/html/lte-design.html, find "buffer size"), check the attribute "MaxTxBufferSize" of LteRlcUm, and check Queue on p2p links you're using...
Bufferbloat is composed by "buffer" and "bloat", so I think that probably buffers should be the first things you study the documentation for.
Nat
Xing Xu
Mar 9, 2016, 12:28:43 PM3/9/16
to ns-3-users
Nat, can you take a look of this thread?
I tried AM, still see packetloss of SOME cases when there is severe inter-cell interference; and it can stuck TCP flow completely. Thanks.
Reply all
Reply to author
Forward
0 new messages