[RPRWG] Comments on the two draft proposals (Transit path design &traffic control aspect only)
Hi all,
With the intention to help find the common ground for both
RPR MAC proposals, I'm trying to list some points here with
regard to the transit path design and traffic control mechanism,
so that we can have a apple-to-apple comparison and debate.
For convinience, nu-draft_01 is designated as A, zz_draft_01 is
designated as B. (Please don't dabate on the designation)
1. What is the "media" a RPR MAC is dealing with ?
Observation: A. 1 clockwise ringlet + 1 counter_clockwise ringlet.
B. N clockwise ringlets + M counter_clockwise ringlets.
Comments: Link Aggregation (in RPR case, Ringlet Aggregation)
should be the job of the MAC Client which could be
served by multiple MACs, with MAC level signalling
support. Why should we burden the RPR MAC with this ?
2. Should the MAC level traffic differentiation be supported ?
Observation: A. Yes, H,M,L classes supported in MAC level.
B. No(?), yes in MAC Client level.
Comments: Are we defining a MAC or a MAC Client ? According to
philosophy of B, do we see the need for Transit Buffer
in the MAC at all ? (I see nothing wrong defining it
as MAC Client function). I think it is time to define
and settle on what kind of logical channel and services
the RPR MAC is presenting to its Client, not what the
Client should behave for the media.
3. Should RPR MAC take ring topology into consideration ?
Observation: A. Yes, with multi-choke scheme running in MAC.
B. Yes, with scheme based on combination of Source-aware
RCM in MAC level and VOQ in MAC Client level.
Comments: It is good to see both A and B realize the importance
of topology_aware access control for the media with
spatial segregation.
Why only up to 4 choke point supported in A ? complexity ?
I thought we have voted on Max. 64 station per RPR ring,
so I guess the complexity should be limited.
My wish for B is to move the VOQ shaping/rate control,
not the VOQ itself, down to the MAC level. Whether the
MAC Client should be topology_aware or not should be
optional.
4. What is the fairness algorithm ?
Observation: A. SRP_fa with multichoke enhancement (hereafter SRP)
B. Source_aware RCM (hereafter RCM)
Comments: It takes some patience to get to the essence of SRP,
believe it or not, it is also an approximation of the
fluid flow model as the obvious foundation of RCM.
One thing the original SRP lack is topology_aware,
therefore the multi-choke enhancement.
The reason for such seemingly different schemes in the
essence of the same model takes root in the transit
path design. RCM will not work well for the transit
path in A, and SRP will not work well for the transit
path in B.
That's all I can think of so far as a naive engineer.
William Dai