|
Bugzilla – Full Text Bug Listing |
| Summary: | Scheduler gives resources to finished flows | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | airremi |
| Component: | lte | Assignee: | Marco Miozzo <mmiozzo> |
| Status: | PATCH PENDING --- | ||
| Severity: | normal | CC: | airremi, bbojovic, manuel.requena, ns-bugs |
| Priority: | P5 | ||
| Version: | ns-3.24 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: |
Test script.
Tentative patch Patch for the scheduler Generation of more RLC queue info |
||
Created attachment 2593 [details]
Tentative patch
Hi,
The issue is broader and as it might have been expected does not only concern UDP.
The problem is that in some conditions the scheduler can keep on scheduling flows that have nothing to transmit. The issue is due to the possibility for the Scheduler to be stuck with a non-empty ReTX queue at the end of the flow.
One way to solve this issue is to modify the RLC AM code to report the buffer status even if all the queues are empty. Not being familiar with the logic I have very little idea about how relevant this modification is.
If this solves the issue, the modified code does not pass the lte-x2-handover test suite. I suspect that this might be a timing issue (as modifying some of the test parameters allows it to pass). But I would appreciate any feedback about that solution.
Output after the patch:
./waf --run capacity-test --command-template "%s -tcp=false"
Using socket factory ns3::UdpSocketFactory
Total RX: 6749936
./waf --run capacity-test --command-template "%s --tcp=false --datarate=0.7Mb/s"
Using socket factory ns3::UdpSocketFactory
Total RX: 6749936
It seems to me a problem related to a bad synchronization between scheduler and RLC-AM. Ideally, when RLC-AM has no more data to transmit the scheduler should have queues to zero, too. I would suggest to check more in depth what is happening (i.e., whether is a bug of scheduler or RLC or an unexpected behavior). The patch solves the symptom, but there might be still a bug in the code. Created attachment 2627 [details]
Patch for the scheduler
Thank you for your reply.
I looked a little bit more into the code of one scheduler (PF-FF) and the issue might be linked to the update of the retransmission queue size. If I understand the code correctly, it appears to be decreased only if the PDU Element size is larger than the whole queue.
Copying the update logic from the transmission queue to allow for a partial decrease seems to solve the issue.
The reason behind this is a requirement of the RLC-AM, which needs TBs of at least the size of the retransmission queue, since it is not implementing the re-fragmentation of the packet in retransmission queue. What I guess it might happen is that we have more than a single packet in the retransmission queue, which implies that RLC transmits but scheduler does not resize the correspondent queue. Therefore, probably the most efficient solution should be to generate more RLC queue info in order to improve the synchronization between the two entities. Created attachment 2629 [details]
Generation of more RLC queue info
I am not sure I follow you. I understand that because the RLC-AM does not perform re-fragmentation of the RLC PDU in the retransmission queue, one of these packets can only be sent when the TxOpportunity is big enough for it to fit entirely. But why would the RLC-AM need TBs of at least the size of the retransmission queue?
Regarding the synchronization between between RLC and scheduler and I think that part of the issue is that the RLC does not send a Buffer Report if all the buffers are empty. This is a problem in this case since the scheduler thinks erroneously that they are not empty.
The patch I submitted first modify both the DoReportBufferStatus function and the expiration of the RBS timer to add that possibility.
Another solution that I have found to work is the patch I submit now. It adds a call to DoReportBufferStatus when a Control PDU is received. For it to work it is also required to modify the DoReportBufferStatus function to allow the RLC to report when all the buffers are empty.
The RLC-AM need TBs of at least the size of the retransmission queue in order to be able to transmit without refragrament. However, in case there is more than one packet in retx queue it is a suboptimal solution and it might fail. Both solution you are proposing are fine with me, but I would ask to RLC maintainer his opinion on this, so I'm putting Manuel in CC. |
Created attachment 2255 [details] Test script. When a UDP flow stops, the scheduler does not seem to release resources for the other flows. I created a small script which creates 2 UEs and 1 eNodeB. - The first UE receives traffic from 1s to 3s - The second UE receives traffic from 14s to 18s - The amount of data received by UE 2 is displayed at the end The second flow is always TCP. If the first flow was UDP the second one will not receive all the bandwidth available. ./waf --run capacity-test --command-template "%s --tcp=true" Using socket factory ns3::TcpSocketFactory Total RX: 6749936 ./waf --run capacity-test --command-template "%s --tcp=false" Using socket factory ns3::UdpSocketFactory Total RX: 3082536 Changing the datarate of the first flow also changes the amount of data transfered by the second flow: ./waf --run capacity-test --command-template "%s --tcp=false --datarate=0.5Mb/s" Using socket factory ns3::UdpSocketFactory Total RX: 6749936 ./waf --run capacity-test --command-template "%s --tcp=false --datarate=0.7Mb/s" Using socket factory ns3::UdpSocketFactory Total RX: 3229936