| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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?
To:
"'Harry Peng'" <hpeng@xxxxxxxxxxxxxxxxxx>, Sushil Pandhi <Sushil.Pandhi@xxxxxxxxxxxxxxx>, Leon Bruckman <leonb@xxxxxxxxxxxxx>
Subject: RE: [RPRWG] Cut through definition? From: Ray Zeisz <Zeisz@xxxxxxxx> Date: Tue, 17 Apr 2001 19:43:09 -0400 Cc: "'davidvja@xxxxxxxxxxx'" <davidvja@xxxxxxxxxxx>, stds-802-17@xxxxxxxx Sender: owner-stds-802-17@xxxxxxxx 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 ------------------------------------------------------------------ |