Bug #4836
ns2: load sharing function for UDP data
100%
Description
Implement the load sharing function for UDP data.
- on a new LSP select a NSVC based on data weight
e.g. count all weight as sum_weight, LSP %modulo sum_weight, select the NSVC.
NSVC1: data weight: 10 NSVC2: data weight: 5 sum = 15, LSP%sum in (0- 9) => NSVC1 sum = 15, LSP%sum in (10-14) => NSVC2
Maintain a LSP table per NSE containing "LSP, NSVC, timestamp/counter". The timestamp is used to remove old entries when the table is full.
Associated revisions
History
#3 Updated by laforge 3 months ago
- Assignee set to lynxis
- Priority changed from Normal to High
Related: load sharing function for FR.
In the FR case, we should assume all weights are equal, and all NS-VC are equally suitable for signaling and user plane traffic.
In the TTCN3 code I chose to simply do a modulo operation of the identifier (LSP) into the array of currently unblocked NS-VCs. That of course means that every time links go up and down there will be a re-assignment of LSP to NS-VC. Some of hat would be avoidable in your list-based approach, but I would argue we can get away with the modulo-based approach. After all, when NS-VCs go down, we inevitably will have a re-distribution of traffic among the remaining NS-VCs. Your approach reduces the number of users/flows that gets redistributed. Not sure if it's worth the effort. The biggest danger in changing NS-VC for an established connection is re-ordering of a few messages.
#5 Updated by lynxis 7 days ago
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
Applied in changeset libosmocore|d8a8d980535468d1f8642cdcf796b2d675c7b8df.
gprs_ns2: implement a simple load sharing for UDP
Implement the load sharing based on modulo of the LSP. As long the gprs_ns2 doesn't
support the resource distribution function (48.016 ยง 4.4a) this simple
approach is good enought.
Fixes: OS#4836
Change-Id: I8c2fe5d647694886ac600470fca6ea5d5d210a85