Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Yong,
Could you eloborate on your comment "RPR over existing SONET infrastructure
should be optimized".
Thankyou
Ashwin
-----Original Message-----
From: Yongbum Kim [mailto:ybkim@xxxxxxxxxxxx]
Sent: Monday, April 30, 2001 4:29 PM
To: Nader Vijeh; 'Donghui Xie'; Stein Gjessing
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RPR Perf: Single vs. Dual ring?]
Dear Nader,
I think # of rings where n=2 should be discussed
as explicit objectives. RPR over existing SONET infrastructure
should be optimized. n=1 may have merits for further
discussions in new applications, such as FTTH, etc.
n>2 may have academic or niche interest today, unless it is over
WDM-enabled SONET infrastructure. If this is the case, n>2 ought
to be discussed in that light.
So my opinion today is to focus on n=2, have a separate
discussion on n=1 (FDDI did allow for this after the initial arch
was done) as well as n>2 (coupled w/ WDM or independent there of).
regards,
Yong.
============================================
Yongbum "Yong" Kim Direct (408)922-7502
Technical Director Mobile (408)887-1058
3151 Zanker Road Fax (408)922-7530
San Jose, CA 95134 Main (408)501-7800
ybkim@xxxxxxxxxxxx www.broadcom.com
============================================
-----Original Message-----
From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On
Behalf Of Nader Vijeh
Sent: Monday, April 30, 2001 11:37 AM
To: 'Donghui Xie'; Stein Gjessing
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RPR Perf: Single vs. Dual ring?]
Whether flow control packets go backward, forward, both ways and/or
hop-by-hop is a question that can be answered after we have agreed on the
requirements.
Does the group agree that the 802.17 MAC should be "able to support" n
homogeneous rings (logical or physical)? Where n could be a number from 1 to
x. x is fixed, such that interoperability is only required between MACs
supporting x rings.
Nader
-----Original Message-----
From: Donghui Xie [mailto:dxie@xxxxxxxxx]
Sent: Monday, April 30, 2001 10:37 AM
To: Stein Gjessing
Cc: stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] RPR Perf: Single vs. Dual ring?]
Hi Stein,
Further with your answers, in dual rings, backward hop-by-hop control
packet gives the fastest response time that is possible, since the control
packet is allowed to go the shortest path to reach the node. As such, the
flow control is less dependent on ring global size, and helps to minimize
the interference with data flows. On the other hand, a broadcast control
packet in single ring has to go the longest path, which not only makes the
flow control be more sensitive to the ring size and distance, but also
subjects the data flows and control flows over the whole ring to mutual
interference.
Donghui
At 03:54 PM 4/28/2001 +0200, Stein Gjessing wrote:
>Samian,
>
> > So, to clarify my understanding, we are using
> > dual rings for flow control packets that propagate hop-by-hop upstream.
>
>Yes.
>
>I believe there already is a (close to) consensus on dual rings.
>Remember that dual rings are also needed for protection.
>
>The flow control packets are, as you say, in a sense broadcasted.
>But on a ring a broadcast needs to go hop by hop.
>And upstream is the sensible way to send the packets, because
>the node that bugs you is most probably closest upstream.
>
> > But, wouldn't it make the simulations easier if we could default to a
more
> > generic flow control scheme,
>
>I believe we have to simulate and understand the flow control schemes
>down to the very details. Small changes in flow control can make big
>changes in performance. Flow control is feedback, and if we don't get
>it right we can get oscillations etc., that are typical for a badly
>controlled feedback system.
>
>Stein
>
>
>------Original Message-----
>Return-path: <owner-stds-802-17@xxxxxxxx>
>Envelope-to: steing@xxxxxxxxxx
>Delivery-date: Sat, 28 Apr 2001 02:30:16 +0200
>From: Samian Kaur <skaur@xxxxxxxxxxxxxx>
>To: "'stds-802-17@xxxxxxxx'" <stds-802-17@xxxxxxxx>
>Subject: Re: [RPRWG] RPR Perf: Single vs. Dual ring?
>Date: Fri, 27 Apr 2001 16:43:50 -0700
>MIME-Version: 1.0
>X-Mailer: Internet Mail Service (5.5.2653.19)
>Content-Type: text/plain;
> charset="iso-8859-1"
>Sender: owner-stds-802-17@xxxxxxxx
>Precedence: bulk
>X-Resent-To: Multiple Recipients <stds-802-17@xxxxxxxxxxxxxxxxxx>
>X-Listname: stds-802-17
>X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx
>X-Moderator-Address: stds-802-17-approval@xxxxxxxxxxxxxxxxxx
>
>
>
>Hi Stein,
>
>Thank you for the explanation. So, to clarify my understanding, we are
using
>dual rings for flow control packets that propagate hop-by-hop upstream.
>
>But, wouldn't it make the simulations easier if we could default to a more
>generic flow control scheme, like maybe broadcasting the control packets.
>This will be a more robust mechanism than hop-by-hop and also eliminate the
>necessity of the second ring. The performance characteristics of this
scheme
>will also give us an insight into the performance tradeoff of this approach
>for comparison.
>
>Do you think a scenario on these lines will be interesting?
>
>Thanks,
>Samian
>
>- -----Original Message-----
>From: Stein Gjessing [mailto:steing@xxxxxxxxxx]
>Sent: Tuesday, April 24, 2001 11:41 PM
>To: stds-802-17@xxxxxxxx
>Subject: [RPRWG] RPR Perf: Single vs. Dual ring?
>
>
>
>Samian,
>
>I agree that a single ring will demonstrate the performance characteristics
>of interest if we disregard flow control.
>Analyzing performance with flow control (by sending flow control
>packets upstream), the dual rings are of course necessary.
>Then the interference between flow control packets and data packets
>also become an interesting issue.
>
>(Also remember that packets are going at most half way around on one ring)
>
>Stein Gjessing
>University of Oslo
>
>
> >Hi Khaled,
> >
> >I know that the performance adhoc committee decided that the Phase I
> >simulations should be done using dual rings. I am beginning to question
if
> >that is necessary. I think a single ring will demonstrate the performance
> >characteristics of interest and save us a lot of run time in running the
> >simulations and is much easier to analyze.
> >
> >Am I missing something?
> >
> >Samian Kaur
> >Lantern Communications