Re: RPR multicast issue
Khaled,
Just to be pedantic :)
I agree that simulation is a very powerful tool, but
proving something with simulation is not easy. Getting
a really strong feeling something works can be done
but for complex state systems, proof is often beyond
computational limits. Having done enough ASIC verification
a powerful simulator and lots of good ideas still often
leaves a chip with bugs.
Having said that, formal tools and methods might
possibly be able to prove completeness.
On the issue of flow control as a simulation parameter
I must have missed that as I don't recall discussions
of mechanism that is similar to xon-xoff having
been discussed.
cheers,
mike
Khaled Amer wrote:
>
> My turn to add my 2 cents:
>
> I have a comment about just one statement made:
>
> > Flow control mechanisms for a ring
> > would be very ugly and difficult to be proven correct.
>
> Not sure I agree with this. Maybe ugly, but don't see why it would be
> 'difficult to be proven correct'. We should be able to prove practically
> anything by simulations (which is what I've been doing for a living for
> quite a while). We can come up with the scenarios that can make or break
> them, simulate them and prove any point. I would agree that it would be
> difficult if we didn't have all the advanced simulation tools that we have
> availble nowadays.
>
> (Of course, as we all know, we've included flow control in the metrics that
> we've been pulling together as well as the first round of scenarios that we
> discussed in the August Interim meeting in Santa Clara)
>
> Just thought I'll provide my 2 cents on this ...
>
> Khaled Amer
> President, AmerNet
> Architecture Analysis and Performance Modeling Specialists
> Phone: (949)552-1114 13711 Solitaire Way, Irvine, CA 92620
> Fax: (949)552-1116 e-mail: khaledamer@xxxxxxx
>
> ----- Original Message -----
> From: "Mike Takefman" <tak@xxxxxxxxx>
> To: "stds-802-rprsg" <stds-802-rprsg@xxxxxxxx>
> Sent: Friday, October 13, 2000 5:56 PM
> Subject: Re: RPR multicast issue
>
> >
> > My $0.02
> >
> > >William Dai wrote:
> > >I imagine the likely implementation of RPR aceess module
> > >would require 3 major interfaces,
> > >East Ring I/F, West Ring I/F, and the Access I/F (for
> > >switch/router connection). In my opinion,
> > >the bandwidth of the Access I/F should be at most
> > >equal to that of a ring I/F for practical reasons,
> > >though you may disagree with me.
> >
> > I don't and I do :). We have implementations of RPR that fit
> > the following categories:
> > Head-End:
> > Can source and sink traffic on both directions
> > at full line rate - this is the aggregation point
> > for a metro access ring or a POP access ring.
> > It could also be a content server (which likely
> > would source at full rate). It could also be
> > peering points between ISPs.
> > Out-station:
> > Can source and sink traffic on both directions
> > at less than line rate. This will be an access
> > box.
> >
> > >The current RPR protocols are trying to guarantee the fairness
> > >of ring resource access, but there is nothing to prevent traffic
> > >flow into the same destination node
> > >from both East and West direstions at the same time,
> > >i.e., input rate = 2x output rate. That is
> > >why I'm saying that congestion could be worse on the RPR
> > >acccess module than on the Ethernet
> > >access module, and that is also why I'm promoting
> > >the importance of flow control integration.
> >
> > I agree that this can happen and for my boxes this is no
> > new issue because that is what congestion mechanism's
> > like RED are for. Flow control mechanisms for a ring
> > would be very ugly and difficult to be proven correct.
> >
> > >Actually, the foundamental issue here is how we view
> > >the RPR scope. If we treat the traffic
> > >managment (along with buffering scheme) as the higher
> > >layer task of switch/router, then the
> > >above is irrelavent, and argueing QoS issue inside
> > >RPR doesn't make sense either.
> >
> > I agree that the discussion is one of scope. Ethernet
> > does not provide traffic management in the MAC layer
> > and support QOS only in that packets are tagged.
> > I believe that RPR should provide some traffic mgt in
> > the MAC layer as well as some support for QOS. But I
> > agree that certain parts of traffic management are
> > outside of the scope of RPR and an inherent part of
> > the value add design of the switch/router. This is
> > true in the ethernet switch world.
> >
> > >On the other question, one of the important differences
> > >between the RPR and a chain of Ethernet
> > >switches is that RPR provide the pass-through buffers,
> > >and RPR protocol is tightly coupled with
> > >it. Pause type of flow control will break all the
> > >proposed schemes, and there is potential ring
> > >lockup problem if we are not careful.
> >
> > That is why I do not advocate that we have signalling that
> > would try to flow control nodes.
> >
> > mike