Re: RPR multicast issue
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