RE: [RPRWG] RPR Perf: Single vs. Dual ring?]
Bob,
I am neither a advocate n=1 nor against it.
That said, n=1 may loosely resemble protection event's
steady state case, but protection-event analysis and
its handling is entirely different problem. Whether in
TR/FDDI or in RPR, the issues are dynamic during the event:
recovery, frame loss, out-of-order issues, reconfiguration
of overall ring, etc, etc.
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: RDLove [mailto:rdlove@xxxxxxxxx]
Sent: Tuesday, May 01, 2001 8:52 AM
To: Yongbum Kim; Nader Vijeh; stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] RPR Perf: Single vs. Dual ring?]
Yong, I would argue that the case for n=1 may be the condition we
effectively have under the fault condition of a line break (Whether we use
steering or wrapping, we will likely be analyzing performance under this
fault condition from an understanding of performance for the case n=1). We
therefore need to carefully analyze and understand this case. I know that
in the development of Token Ring, the lions share of the work was in
analyzing what happens under fault conditions. It is only by understanding
what happens during faults that we start to understand the resiliency of our
protocol.
Best regards,
Robert D. Love
Chair, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@xxxxxxxx Fax: 720 222-0900
----- Original Message -----
From: "Yongbum Kim" <ybkim@xxxxxxxxxxxx>
To: "Nader Vijeh" <nader@xxxxxxxxxxxxxx>; <stds-802-17@xxxxxxxx>
Sent: Monday, April 30, 2001 10:34 PM
Subject: RE: [RPRWG] RPR Perf: Single vs. Dual ring?]
>
> Dear Nader,
>
> Just to clarify my opinion, I believe n=2 is
> the normal case, and n=1 and n>2 should be argued by
> respective proponents. I cannot form an opinion without
> understanding the scope and application of both.
>
> On n=2: RPR that does not take advantage of existing
> SONET infrastructure (not necessarily framing, but
> optical paths) is not as attractive in the Metro/WAN
> space.
>
> 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 6:28 PM
> To: stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] RPR Perf: Single vs. Dual ring?]
>
>
>
> Agreed. Basically, the question is whether the MAC definition should limit
> the scope to a dual ring or should the 802.17 MAC objectives include a MAC
> with n phy interfaces?
>
> As Yongbum noted, there are applications for n>2 (DWDM) and applicability
> for n=1 can also be argued. The objective n=1..N, where N>2, covers the
> special case of n=2 and satisfies support for the case of dual rings.
> Comments please!
>
> Nader
>
> -----Original Message-----
> From: jeanlou.dupont@xxxxxxxxxxx [mailto:jeanlou.dupont@xxxxxxxxxxx]
> Sent: Monday, April 30, 2001 12:11 PM
> To: Nader Vijeh
> Cc: stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] RPR Perf: Single vs. Dual ring?]
>
>
>
>
>
>
> I guess that a "physical" implementation of an RPR MAC could support "n"
> homogeneous rings.
> But in terms of "logical" MAC, only one homogenenous ring per MAC should
be
> standardized. A bridging/switching/routing function can forward packets
> between
> the homogeneous rings.
>
> jld.
>
>
>
>
>
> -----Original Message-----
> From: Yongbum Kim [mailto:ybkim@xxxxxxxxxxxx]
> Sent: Monday, April 30, 2001 1: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
> ============================================
>
>
>
> Nader Vijeh <nader@xxxxxxxxxxxxxx> on 04/30/2001 02:36:45 PM
>
> To: "'Donghui Xie'" <dxie@xxxxxxxxx>, Stein Gjessing <steing@xxxxxxxxxx>
> cc: stds-802-17@xxxxxxxx (bcc: Jeanlou Dupont/MAIN/MC1)
>
> 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
>
>
>
>
>