|
Hi,
A way to solve this problem is by
allowing parameters in the fairness algorithm for access to the ring to vary
within different implementations. These parameters could define transit buffer
latency, control packet latency, number of transit buffer priorities, etc.. In
this case, a MAC device that is designed to support a higher quality set of
parameters can contain more buffering and utilize a store and forward approach,
while a MAC device designed to support a lower quality set of parameters can
contain minimal buffering and utilize a cut-through approach. Pre-emption can
then be not considered as jumbo frames can be delegated for low priority
buffers. Network equipment manufacturers can then determine the quality of MAC
devices they need to use in their products.
Thanks,
Cliff Davis
Pr. Engineer
ADC The Broadband
Company
8 Technology Dr.
Westboro, MA 01581
(508) 870-2506
cliff_davis@xxxxxxx
----- Original Message -----
Sent: Thursday, April 19, 2001 3:35
PM
Subject: RE: [RPRWG] Cut through
definition?
If
we allow pre-emption, at least we need to specify what are the boundary
conditions a reciever is
expected to handle. Thus could there be very small
fragment (say 32 bytes) coming from xmitter
or
it will me made sure that receiver does not see any unusual behavior on
account of the
xmitter implementing pre-emption
?
Regards,
Devendra Tripathi
VidyaWeb, Inc
90 Great
Oaks Blvd #206
San Jose, Ca 95119
Tel: (408)226-6800,
Direct:
(408)363-2375
Fax: (408)226-6862
Dear Ray
1) Nothing prevents that nodes with cut-through
and nodes with store-and-forward can work together.
2) Also different buffer scheduling mechanisms
can be used.
3) Even a different number of buffer classes in
the nodes works when a class mapping scheme is agreed on.
There will certainly be a difference in the
performance of the nodes, but the standard should leave freedom as much as
possible. No special configuration should be mandatory. Equipment
manufactures and network operators should decide.
Preemption is less complex than is claimed in
all email-responses. Also preemption should in fact remain a degree of
freedom. Nodes with and without preemption can perfectly exist in the same
ring, if the ring input-part of each node can handle
preempted packets so that preempted and preempting packets are received
correctly. If we not agree that all ring-input parts must understand
preemption, then at least the standard should allow that those
nodes designed for preemption are conform to the standard. In that
case, a preemptive node will not use the feature when the next node is not
preemptive. Again equipment manufactures and network operators should be
able to decide whether it will be necessary to have packet preemption or
not. There, are a lot of countries, a lot of applications, and not at last
cost-considerations, where the features of resilience and QoS is very
important, but where lower bit rates like 155/622 Mbit/s perfectly fit, and
that still for a long time to go. Here, voice-like applications and large
data frames ask for preemption.
With respect to jumbo packets, I like to ask
who really knows what the right MTU for future high-performance applications
will be. If the use of RPRs should be transparent in a variety of network
environments, then again equipment manufactures and network operators should
decide on the MTU in their products and their application,
respectively. The standard should allow again for freedom, however requiring
of course a minimum MTU.
What I advocate is that the standard should
guarantee interworking, but manufacturers should have some design freedom to
differentiate in the performance and cost features of their
products.
Best regards, Harmen
Original message
RE: [RPRWG] Cut through
definition?
Title: RE: [RPRWG] Cut through definition?
I
agree with Harry on the complexity issues. It is a resilient PACKET
ring. If the user wants granularity smaller than packets they can
readily buy SONET equipment.
And how would we signal that a packet is
being pre-empted and remain PHY agnostic? It seems that some sort of
control character would need to be agreed upon for the pre-emption...but I
digress.
There has been a lot of debate on the cut-through
issue, but one thing that has not really come out is the ability to
implement RPR with existing technology. I have read the Cisco RFC on
SRP and have found nothing in that RFC that would prevent me from going out
and buying an off the shelf Network Processor and implementing that
protocol. Once the IEEE 802.17 dictates that store and forward is not
acceptable, the ability to do that is removed. If cut-through is
required, then we just added 18-months to the availability date of working
802.17 products, since new silicon will be required. Of course, there
may be companies out there that already have silicon in the works....and
would like to require cut-through operation as a way to maintain a barrier
to entry in this market. (I am not trying to say anyone is doing this
with .17, but I have seen that kind of activity in other standards
bodies.)
As far as the number of classes of service to
support: I initially thought that it would be nice to have many (i.e.
8) classes of service as well as their behavior dictated by the .17
standard. After following the reflector the last few weeks it seems
that would be totally the wrong thing to do. I am now wondering if
anyone would be in support of not standardizing multiple classes of service
at all, and instead simply requiring nodes to implement a fairness algorithm
that ensures a configurable percentage of the data stream from the ring is
propagated through the node. For example, on a 1 G ring, with 10 nodes
could we not configure each node to ensure that it provides priority to the
transit buffer with a 9:1 ratio? I realize that there is a lot of work
going into fairness algorithms, but maybe those should be vendor
differentiators and not standardized. That goes for the pre-emption
feature too....if all the nodes could communicate and agree that they
understand pre-emption then it could be used, as an option.
I
do not work for a silicon vendor, I am looking at these problems from a
systems provider point of view. I would really like to see some more
"real life" requirements and input on these subjects from the carriers and
service providers that will be buying the equipment. If they are out
there, please speak up.
Regards, Ray
------------------------------------------------------------------
Prof.Dr.
Harmen R. van As Institute of
Communication Networks
Head of
Institute
Vienna University of Technology
Tel
+43-1-58801-38800
Favoritenstrasse 9/388
Fax
+43-1-58801-38898
A-1040 Vienna, Austria
http://www.ikn.tuwien.ac.at
email: Harmen.R.van-As@xxxxxxxxxxxx
------------------------------------------------------------------
|