Project

General

Profile

Bug #4836

ns2: load sharing function for UDP data

Added by lynxis 28 days ago. Updated 10 days ago.

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

0%

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.

History

#1 Updated by daniel 28 days ago

  • Description updated (diff)

#2 Updated by laforge 10 days ago

  • Category set to libosmogb

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)