RE: [RPRWG] Response to comments, Weighted Fairness, July meeting
Please run the simulation scenario as following:
Ring is as following:
0 1 2 3 4 5 6 7
15 14 13 12 11 10 9 8
Please have Node 0 sends traffic to node 1 and node 7
Node 1 sends traffic to node 2 and node 7
Node 2 sends traffic to node 3 and node 7
Node 3 sends traffic to node 4 and node 7
Node 4 sends traffic to node 5 and node 7
Node 5 sends traffic to node 6 and node 7
Node 6 sends traffic to node 7
This is a half ring
Do the same thing for the other half of the ring.
Please have Node 8 sends traffic to node 9 and node 15
Node 9 sends traffic to node 10 and node 15
Node 10 sends traffic to node 11 and node 15
Node 11 sends traffic to node 12 and node 15
Node 12 sends traffic to node 13 and node 15
Node 13 sends traffic to node 14 and node 15
Node 14 sends traffic to node 15
Then measure the throughput on each link. You will see that thoughput on
each link is not close to 100% because of the head of a line problem.
This a single simulation scenario. Many others can be constructed that are
very realistic.
Whenever you have traffic destined for more than one destination,
you will see head of the line blocking problem.
Head of line blocking can be explained very simply. In the ring if station 0
has two aggregate flows to send to station 2 and station 5. If the link
between station 4 and station 5 is congested, station 4 will send the
appropriate congestion avoidance/rate shaper parameter information to
station 0. This will slow or block the frames destined for station 5. When
frames destined for station 5 reach the head of the add queue, the frames
destined for station 2 will be slowed or blocked by the frame(s) destined
for station 5. This is head of line blocking.
Having more than one destination for traffic sourced from a single node is
very realistic scenario for career services. To name a few
Metro Transparent LAN services,
Peering sites and NAPs
etc.
Sanjay K. Agrawal
Principle Engineer
Luminous Networks
-----Original Message-----
From: Carey Kloss [mailto:ckloss@xxxxxxxxxxxxxxxx]
Sent: Monday, August 13, 2001 3:22 PM
To: stds-802-17@xxxxxxxx
Subject: [RPRWG] Response to comments, Weighted Fairness, July meeting
This e-mail is a follow up to one of AuroraNetics' presentations from
the July meeting (title: "Providing Enhanced Fairness", July 2001)
In it, we replicated a traffic scenario from a previous Lantern
presentation: (title: "Performance Issues and Requirements",
May 2001 meeting, slide #10 of 16).
Links to the two papers are:
http://www.ieee802.org/17/documents/presentations/jul2001/nu_efa_01.pdf
http://www.ieee802.org/17/documents/presentations/may2001/ahm_pir_02.pdf
The Lantern scenario points out a performance issue with standard SRP.
AuroraNetics' presentation compares the standard SRP results with our
new "Weighted-Fairness" congestion control mechanism with favorable
results.
In the question and answer session following our presentation, there
were some comments from the audience that we would like to address:
1. Sanjay Agrawal thought that the scenario that we simulated was not
the same as Lantern's scenario
2. Raj Sharma recommended that we rerun adding some mesh traffic to
our hub-only scenario
For #1, the scenario we ran was this:
- OC-12 ring, outer ring only
- Single Hub scenario
- 8 nodes
- Each non-hub node sources 300Mbps destined to the Hub node
- Hub sources 700 Mbps, 100 Mbps destined to each non-hub node
We ran this scenario with standard SRP, and got the same results as
Lantern. Each node was limited to ~622/7, including the Hub node. We
also ran with AuroraNetics' Weighted-Fairness algorithm, which enabled
us to fully utilize the bandwidth on all links. (The hub node was no
longer limited.)
We believe that this traffic scenario is exactly the same as the one
presented in Lantern's paper. If it's not, please let us know how it
differs and we will re-run.
For #2, we reran the same scenario adding both high priority and low
priority mesh traffic in varying ammounts, and the results were still
favorable. Without Weighted-Fairness, the hub node was throttled as
expected, and only the last link was fully utilized. With Weighted-
Fairness, however, every link reaches 100%.
Thanks,
Carey Kloss
AuroraNetics