Fundamental eDRX design choices by Verizon breaking functionality

RE: Fundamental eDRX design choices by Verizon breaking functionality

jbrzozoski — Thu, 30 Jan 2020 21:01:02 GMT

Martin Lesund please pass along my follow-up feature request here. It's not a total solution to the issue, but it would help a lot.

RE: Fundamental eDRX design choices by Verizon breaking functionality

Martin Lesund — Wed, 18 Dec 2019 12:08:23 GMT

Hi Justin,
As for now, this is the workaround I would recommend this issue.
Looking into how we can improve this, but let me come back to you when I have more information.

Best regards,

Martin L.

RE: Fundamental eDRX design choices by Verizon breaking functionality

jbrzozoski — Mon, 16 Dec 2019 19:17:02 GMT

I saw the CSCON suggestion from Nordic on this ticket, but am still hoping for more commentary or wisdom.

The CSCON does flip to 1 when we get the symbolic page from Verizon, but the symbolic page doesn't seem totally reliable, and am hoping for either another method or some indication that the symbolic paging could be improved.

RE: Fundamental eDRX design choices by Verizon breaking functionality

jbrzozoski — Thu, 12 Dec 2019 17:14:40 GMT

[quote userid="77106" url="~/f/nordic-q-a/55473/fundamental-edrx-design-choices-by-verizon-breaking-functionality"]One final symptom we see when a packet is discarded is that the Verizon towers will often page the mobile device to generate a service request, bringing it out of the normal eDRX cycle into a full RRC connection, but then not provide any data.[/quote]

This behavior is extremely inconsistent and frequently doesn't happen. We're now wondering if we misunderstood our Verizon contact concerning this being intentional, or if it just behaves very different than we expect. In either case, we don't think it will be usable as a hint that the server is trying to reach the mobile device.

RE: Fundamental eDRX design choices by Verizon breaking functionality

GNotman — Thu, 12 Dec 2019 15:00:31 GMT

I believe that MQTT (at least over TCP) is fundamentally incompatible with eDRX, as even the networks that support buffering may limit the number of buffered packets. For example one network here in the Netherlands told us that they buffer a single packet per eDRX cycle, for up to the duration of one eDRX cycle and attempt to deliver it once at the very next PTW. If more than one packet is sent to the end device during the idle phase of the eDRX cycle, then a replace strategy is used within the buffer. I believe such behaviour will cause issues trying to maintain any TCP socket.

I am curious how Verizon handles Non-IP Data Delivery with eDRX, as that might a better alternative to using SMS delivery.

RE: Fundamental eDRX design choices by Verizon breaking functionality

jbrzozoski — Wed, 11 Dec 2019 20:04:21 GMT

Another clarification: it looks like sometimes the Linux server stops sending new TCP data down to the mobile device when it knows that the prior packet hasn't been ACKed. The end result looks similar, but in this case data is being buffered on the server's TCP stack instead of on the mobile client's stack... This will make it harder for the mobile client to detect that it's in a lost packet state. 😞

Again, the best way to detect might be to send an application level message that should get an immediate response, like an MQTT keep-alive, and correlate the fact that the TCP sequence has been ACKed but the PINGRSP was never received as a hint that we're stuck.

I've been playing with Linux TCP sysctls on our server today, so I'm not sure if this is changed behavior because of one of those or if I was just lucky before.

RE: Fundamental eDRX design choices by Verizon breaking functionality

jbrzozoski — Wed, 11 Dec 2019 19:36:59 GMT

Okay, in my digging through various bits of Linux TCP documentation and source code, I've seen that receiving two ACKs for the same TCP sequence number is taken by Linux (in most situations) as a hint to immediately re-transmit the packet just *after* that sequence number. Maybe when our system detects it is in this packet-lost state, the modem could send an extra ACK to the previously ACKed sequence number. That should trigger an immediate resend from the server that would hopefully land in the current RRC period.