Re: [RPRWG] Response to comments, Weighted Fairness, July meeting
Hi Raj,
Sorry if this wasn't explained clearly enough in the slides, but here are the
answers to your questions:
1. 7 Nodes * 1.5G = 10.5G, but the links can only handle 10.
2. Given that, all links will be congested on and off (perhaps the text was
misleading here)
3. The reason we singled out node 7 is because once node 7 gets congested, its
usg. message will slow ALL of the other nodes to match its rate.
4. We created this simulation as a generic version of lantern's scenario,
trying to create a more real-life case. We think that a ring with 2 hubs, one
sinking and one sourcing is more realistic and generic than lantern's single
hub pathological scenario.
So in normal SRP, when the downstream nodes (any of them) become congested
(due to the 10.5G>10G), they will throttle the upstream Hub node to 10G/7=
~1.4G. This will cause the upstream links to be under-utilized
With Weighted Fairness, you can give priority to the Hub node, allowing it to
send ~10G, thus fully utilizing all of the links.
Raj Sharma wrote:
> Hence at the meeting I did not understand what Auroranetics
> was trying to prove and wanted to pose some "real and common" problems that
> can be simulated.
Just to further clarify, this presentation was a specific rebuttal to
Lantern's previous slides, and this second case was just a generalized
version, which we believe is more likely to happen than Lantern's first simple
case. This was NOT a generic solution to every possible scenario.
As for the results adding random traffic, I can create some slides and mail
them out to you if you're interested, but the results were basically identical
to the graphs presented in the paper. Let me know if you want copies.
Regards,
--Carey
Raj Sharma wrote:
> Hi Carey,
>
> I would like you to revisit Auroranetics' presentation "nu_efa_01.pdf"
> for reference in my discussion below. Consider the slide (6th) for "example
> 2
> (generalized)" in which there are 8 nodes shown (1 through 8 numbered
> clockwise) nodes #1 and #8 being the 2 hub nodes.
>
> In this example Hub Node #1 sends downstream to each node 2, 3, 4,.
> ....8 of 1.5 Gbps worth of traffic. So, Hub Node's egress rate
> is 10.5 Gbps (7 X 1.5). (red lines)
> So, each node (2 thru 8) takes off 1.5 Gbps from the ring.
> However, each node (2 thru 7) also adds 1.5 Gbps to the ring
> destined for node 8 (blue lines) in the same ring direction as the
> traffic from node 1.
>
> This means, effectively the egress rate at nodes 2 through 7
> will always be 10.5 Gbps in the clockwise direction. Since 1.5
> drop and add does not change the ingress and egress rate at any node
> in the same direction of the ring.
>
> First of all, I don't understand what that slide was trying to
> show. It claims that node 7 is congested. From the above analysis
> I don't understand what is so special of node 7 in that example.
> It claims links 1 to 6 maybe under utilized - not according to my
> simple mind !!
> It claims node 1 cannot send enough traffic to destination nodes
> - But why - since node 1 has no ring ingress traffic shown !!!
>
> As per my calculations shown above all the links considered in the
> simulation
> have the same amount of traffic because each node sinks and sources the
> same amount of traffic.
> There is no difference at any node. This example is what I usually
> refer to as "pathological" case study.
>
> I somehow felt that simulations were used to confound people out their
> common sense and dumb-found them.
>
> Hence at the meeting I did not understand what Auroranetics
> was trying to prove and wanted to pose some "real and common" problems that
> can be simulated.
>
> Hope that first clarifies the reason why such questions are raised.
>
> Regarding my question about mixing meshed traffic with hub and spoke
> traffic I guess we have to take your word that it works !!
>
> Simply, HOL problem cannot be solved if you do not have
> have the ability to schedule packets on any outgoing link
> based on its destination node address and the weighting factor (in terms
> of BW usage) associated with that destination.
>
> I am sure simple minds think alike !!
>
> Raj
>
> -----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
>
> ------------------------------------------------------------------------
> Name: nu_efa_01.pdf
> nu_efa_01.pdf Type: Portable Document Format (application/pdf)
> Encoding: base64
> Download Status: Not downloaded with message