Feature #6303
openConvert pcuif to TLV to make backwards compatibility more feasible
0%
Description
In a meeting today with pespin and fixeria, we figured it would be useful to have a TLV based PCUIF protocol so we could extend it in the future without always breaking backwards compatibility. If it was backwards compatible, we would not need to have osmo-pcu, osmo-bts and osmo-bsc all speak the exact same PCUIF version as it is currently the case.
Updated by laforge 4 months ago
I really don't think we want to do future changes to the PCU interface at all.
I'd hope that in 2023 we finally reach a point where we can consider a lot of the
code base going more into maintenance mode rather than continuing large feature
developments which introduce breaking changes.
You also always have to keep in mind the use on CPU constrained systems like sysmoBTS,
where additional parsing overhead might matter.
I'm therefore not in favor of spending a lot of time converting all PCUIF users
to yet another new protocol/encoding where it's unclear if we ever will need it,
and whether it will generate performance problems on old sysmobts hardware.
Updated by fixeria 4 months ago
laforge wrote in #note-1:
I really don't think we want to do future changes to the PCU interface at all.
I'd hope that in 2023 we finally reach a point where we can consider a lot of the
code base going more into maintenance mode rather than continuing large feature
developments which introduce breaking changes.
Interestingly enough, those last few PCUIF versions were introduced not in the scope of adding new features, but actually in the context of fixing long-standing problems we had.
You also always have to keep in mind the use on CPU constrained systems like sysmoBTS,
where additional parsing overhead might matter.
It should be clarified that the actual idea was to use TLV based encoding not for all PCUIF messages, but only for the INFO.ind.
This message is not as "hot" as DATA.{ind,req}, for instance, so I would not expect any significant performance impact.
I'm therefore not in favor of spending a lot of time converting all PCUIF users
to yet another new protocol/encoding where it's unclear if we ever will need it,
and whether it will generate performance problems on old sysmobts hardware.
I agree that doing another PCUIF version bump just for improving the coding/flexibility of INFO.ind is not reasonable.
But if we ever have to extend the PCUIF again, I believe we should take a chance and move to TLV based coding for INFO.ind.
This way we could avoid bumping PCUIF version again and again when adding new fields.
