Implementing Custom Buffer in RLC: NS_ASSERT Error "DC bit == DATA_PDU"

[Maria Eduarda Veras Martins]

I am trying to implement a different type of buffer for the RLC. I have already set up communication with the other layers and created functions similar to the existing ones. When I add a function similar to DoNotifyTxOpportunity, which follows the same steps but is modified to take from my new buffer, I get the following error:
NS_ASSERT failed, cond="m_dcBit == DATA_PDU", +2.038028563s 0 file=/home/maria/l4s-rlc/src/nr/model/nr-pdcp-header.cc, line=103
NS_FATAL, terminating

My guess is that this happens when the packet needs to be fragmented by the buffer, but I haven't found anywhere that addresses this in the standard implementation. Does anyone know how I can resolve this?

Thank you.

[Tom Henderson]

There are two possible reasons, in general, why you may hit this assert:

1) you added a PDCP header but did not set the DC bit (check if
NrPdcpHeader::SetDcBit is being called)

2) you are trying to deserialize (Peek or Remove) a NrPdcpHeader from a
Packet but such header doesn't exist there, either because you have
already removed it earlier, it was never added, or there was some
segmentation and you are trying to read the header from the middle of a
packet

- Tom

> --

[Maria Eduarda Veras Martins]

In fact, the error occurs on line 286 when the packet has been fragmented. My question is how it works with the default rlc buffer, since it also fragments the packets... 
In the DoNotifyTxOpportunity function there is nothing about adding headers when segmentation occurs, the packet is just added to the buffer again.

--
You received this message because you are subscribed to the Google Groups "5G-LENA-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 5g-lena-user...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/e0db4154-d212-fafb-1f9b-b9a769d80865%40tomh.org.

[Kent Huns]

I once reported a similar error. probably the same cause. > https://gitlab.com/cttc-lena/nr/-/issues/123

In the case of RLC-UM, this error occurs when FI=10=|0|1|, that is fragmented packets.

DC bit is always checked in the current implementation regardless of whether it is defined or not.

so It's better to define m_dcbit as "0=CTRL_PDU" or "1=DATA_PDU" if you could.

[Maria Eduarda Veras Martins]

Hi Kent,

I noticed in my implementation that when the packet was fragmented, it was being added to the end of the buffer instead of the beginning. After making this change, the error regarding the DC bit was resolved. However, the current error I am encountering is:

msg="Removing unexpected header.", +2.048028563s 0 file=/home/maria/l4s-rlc/src/network/model/packet-metadata.cc, line=699 NS_FATAL, terminating terminate called without an active exception

I was able to use gdb to trace the source of this error, and I found that it originates from the function TcpSocketBase::ForwardUp. Moreover, I think that the error occurs because the TCP header is fragmented, as shown in the attached figure. Do you have any insights on this issue?

[Kent Huns]

Hi Maria,

>> msg="Removing unexpected header.", +2.048028563s 0 file=/home/maria/l4s-rlc/src/network/model/packet-metadata.cc, line=699 NS_FATAL, 

I remember getting this message when I commented out "NS_ASSERT(m_dcBit == DATA_PDU)" in RLC-UM.

Please check attached image. I think this error is due to the definition of your header & UM's header.

(If the bug of src/network/model/, it's quite serious problem for all ns-3 users.)

We need to check how "uid"&"deserialize" are determined, and how should be determined.

[Maria Eduarda Veras Martins]

Hi Kent, 
I also found this function in packet metadata. But checking the variables I found that my uid id ok. My problem is with size...
I'am getting size=20 and item.size=32

To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/83ef40ce-1c1c-4731-8ab4-ebecb273d38bn%40googlegroups.com.

[Kent Huns]

Okay, could you tell me which is the expected header size?
Is 32 bits too much? or 20 bits too little?

[Maria Eduarda Veras Martins]

To be honest, I'm still unsure about what the correct size for the header should be. I know that the issue arises when trying to remove a TcpHeader. Additionally, I noticed that the problem occurs when the TCP header is treated as a fragment, but I wasn't aware that headers could also be fragmented.

In the log at line 1315, I found the following output:

[node 0] TcpSocketBase:DoForwardUp("ns3::TcpHeader Fragment [0:8] ns3::NrPdcpHeader (D/C=1 SN=5) ns3::Ipv4Header (tos 0x1 DSCP Default ECN ECT (1) ttl 63 id 3 protocol 6 offset (bytes) 0 flags [none] length: 588 2.0.0.2 > 7.0.0.2) ns3::TcpHeader (49153 > 1235 [ACK] Seq=537 Ack=1 Win=32768 ns3::TcpOptionTS(2023;2003) ns3::TcpOptionEnd(EOL)) Payload Fragment [24:486]")

Attached is where the issue occurs, which I discovered while debugging with gdb and performing a backtrack.

To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/457e1089-2f40-4094-a461-9262ca54bc96n%40googlegroups.com.

[Biljana B.]

Hi Maria, 

I am sorry for replying late, I somehow thought that you had seen an open issue in 5G-LENA Gitlab for this, but maybe you did not. Here is the link: https://gitlab.com/cttc-lena/nr/-/issues/123. All the conclusions you may have would be good if you could add to that issue. Especially, if you have a simple example that allows someone else to reproduce and debug the issue please add the example to issue 123 and hopefully, someone will resolve it.

In my comment on that issue, I provide a commit that is a workaround to this. I have noticed in really huge simulations that this issue happens extremely rarely, so basically this workaround in such cases just skips that packet so the simulation can continue. I have traced how many times this happened, and was insignificant compared to the simulation duration. I never had a small example that was debuggable, I was only detecting this issue in a huge simulation setup with 1000 nodes, and after a lot of simulation time. So for me, this workaround was OK. Hope this helps.

Kind regards,

Biljana 

[Maria Eduarda Veras Martins]

Hi Biljana,
I was able to solve this problem yesterday in my simulation, as you can see in previous messages in this thread
But thank you very much for the answer!