Project

General

Profile

Bug #3728

Problem using compressed ACK/NACK bitmaps or uncompressed bitmaps without length

Added by laforge 5 months ago. Updated 1 day ago.

Status:
In Progress
Priority:
Urgent
Assignee:
Target version:
-
Start date:
12/13/2018
Due date:
% Done:

0%

Spec Reference:
TS 44.060 (9.1.8|12.3)

Description

The issue is with uplink ACK/NACK coding in case of using compressed bitmaps or uncompressed bitmaps without length.

This issue is reproducible, kluchnikov made tests with FTP uploading and after some period of time uplink just stalled forever, until it timed out. They made a workaround for this issue, forced uncompressed bitmaps with length and uplink worked in this mode, but other modes should be fixed.

History

#1 Updated by msuraev 5 months ago

kluchnikov please share as much details on how to reproduce this as possible:
- config files
- how processes are started
- what have to be changed to enable the workaround
- any particular reason for choosing FTP upload (vs http, scp etc) for test case?
- how long we have to wait, how do we know issue is triggered (particular pattern in the logs?)
etc.

#2 Updated by laforge about 1 month ago

  • Assignee set to lynxis
  • Priority changed from Normal to Urgent

#3 Updated by lynxis about 1 month ago

  • Status changed from New to In Progress

#4 Updated by lynxis about 1 month ago

  • Subject changed from Problem using compressed ACK/NACK bitmaps or uncompressed bitmaps witout length to Problem using compressed ACK/NACK bitmaps or uncompressed bitmaps without length

#5 Updated by lynxis about 1 month ago

  • Spec Reference set to TS 44.060

#6 Updated by lynxis about 1 month ago

  • Checklist item check if RLC tests are possible in our TTCN3 added
  • Checklist item create a TTCN3 testplan added

#7 Updated by lynxis 24 days ago

  • Spec Reference changed from TS 44.060 to TS 44.060 (9.1.8|12.3)

#8 Updated by lynxis 1 day ago

  • Checklist item deleted (create a TTCN3 testplan)

I've stopped implementing TTCN3 tests and switched over to an experiment based approach.

So far uploading of a 2MB to a FTP works, however in my lab environment, there was no packet lost and because of this, there were no compressed ack, even when activated.
While testing, I've noticed a high retransmission statistics counter, while looking closer, the PCU is sending a single RSL package multiple times without using the window size.

#9 Updated by laforge 1 day ago

Hi Lynxis,

On Sat, May 25, 2019 at 09:49:58AM +0000, lynxis [REDMINE] wrote:

however in my lab environment, there was no packet lost and because of
this, there were no compressed ack, even when activated.

use a wired setup with attenuators or otherwise get close to the
sensitivity limit? We have plenty of attenuators including rotary step
attenuators that can be manually controlled.

While testing, I've noticed a high retransmission statistics counter, while looking closer, the PCU is sending a single RSL package multiple times without using the window size.

are you sure that's not simply the "blind pre-emptive retransmission if nothing else is
to be transmitted"? See https://osmocom.org/issues/2408 - if it is, it might be worth
first implementing a VTY option to disable that to avoid confusing you in the traces.

#10 Updated by ipse 1 day ago

laforge wrote:

Hi Lynxis,

On Sat, May 25, 2019 at 09:49:58AM +0000, lynxis [REDMINE] wrote:

however in my lab environment, there was no packet lost and because of
this, there were no compressed ack, even when activated.

use a wired setup with attenuators or otherwise get close to the
sensitivity limit? We have plenty of attenuators including rotary step
attenuators that can be manually controlled.

I'm not sure which BTS you're using for the tests but if it's osmo-bts-trx then it defaults to MCS-1 due to lack of the C/I data coming to the PCU. Try forcing it to MCS-9 to have a higher probability of packet loss - this really helped in our testing.

#11 Updated by lynxis 1 day ago

laforge I'll look into it, if this is a "blind pre-emptive retransmission" and add a vty for it.

Try forcing it to MCS-9 to have a higher probability of packet loss - this really helped in our testing.

ipse Thanks, good idea.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)