Project

General

Profile

Bug #4836

ns2: load sharing function for UDP data

Added by lynxis 11 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
libosmogb
Target version:
-
Start date:
10/27/2020
Due date:
% Done:

100%

Spec Reference:

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

Revision d8a8d980 (diff)
Added by lynxis 7 months ago

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

History

#1 Updated by daniel 11 months ago

  • Description updated (diff)

#2 Updated by laforge 10 months ago

  • Category set to libosmogb

#3 Updated by laforge 10 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.

#4 Updated by lynxis 7 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 80

#5 Updated by lynxis 7 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)