RE: [RPRWG] Comments on the two draft proposals (Transit path design &traffic control aspect only)
William,
I am glad you are raising these questions, because the group as a whole
is going to have to reach consensus on these issues if the standard is
going maintain its schedule. The answers to these questions are not
simple, which is why the group is divided. The thing that makes these
questions tough to answer is due to the transit path being part of the MAC.
From what I've seen, both A and B agree on the transit path being part
of the MAC.
1. The basic model consists of a MAC which services dual ringlets. The
question
for group B which is proposing the multiple ringlets is whether they
envision this being a single MAC N:M ringlets, or are multiple instances
of dual ringlet MACs connected to a common client?
How is congestion avoidance/management administered over these links?
Do the ringlets terminating at a given station share a single MAC address?
2. The issue is not whether the buffer resides in the MAC or in
the client. Both A and B require Ingress buffering within the client
and both require some form of buffering in the transit path, but differ
on the nature of the transit path buffer and in the way traffic is admitted
to the ring. The question the group needs to determine is whether
or not having a 1 buffer solution in the transit path is better than the
the 2 buffer solution for the range of supported network deployment
scenarios.
Is one better than the other for all scenarios, or is there a split for
some networks versus others. If it turns out the solution is bi-modal, then
we are
better serving the RPR service provider market by allowing both as opposed
to selecting 1 and precluding the other. Most other data/telecom
standards focus on the external behavior (between network devices) and
offer recommendations regarding techniques used inside the devices.
You are correct in pointing out, "we kind of logical channel and services
the RPR MAC is presenting to its Client, not what the Client should
behave for the media". This is what we should be focussed on regarding the
transit path of the
MAC. I don't see why we should not be able to reach consensus by
having provisions in the standard for both a 1 buffer and 2 buffer transit
path design, and getting on with the things you mention.
3. The more general solution should not be to limit congestion
management to 4 domains. The MAC should be capable of relaying
per station congestion messages upstream. It should be up to the
client as to how to interpret these messages. In this case the
congestion avoidance is better suited in the MAC client. The client
implementation determines how many congestion domains is supported.
The number of rate control/shapers should include not just the
number of stations but also the number of supported traffic classes
(services to the client). With an additional 3x or 4x factor, do
you still recommend this function be part of the MAC or the client?
4. The proponets of A. suggested coexistence of both the single and
multiple buffer transit path design. It would be interesting to hear
from them on what mechanisms would be required for one to work well
with the other. If we standardize on the rate control messages
and nodes adhere to them, then they should be able to coexist.
SRP control loop can probably be modified to support RCM type messages.
Upstream RCM node should not have a problem with a downstream
SRP node. The upstream SRP node may need to be more responsive
and maintain stricter adherence when receiving
upstream rate control messages from an RCM node.
thanks,
bob
Robert Castellano
Jedai Broadband Networks
rc@xxxxxxxxx <mailto:rc@xxxxxxxxx>
(732) 758-9900 x236
-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of William Dai
Sent: Tuesday, September 25, 2001 3:53 PM
To: stds-802-17@xxxxxxxx
Subject: [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