Re: [RPRWG] Cut through definition?

["Harmen van As" <Harmen.R.van-As@xxxxxxxxxxxx>]

Dear William

 

I am convinced that this type of freedom of the nodes has no impact on interoperability except performance.

 

What needs to be standardized here is:

- the number of classes

- the way of mapping when less parallel RX, IB, and TX buffers are supported in a node

- the fairness mechanism coordinating medium access between all nodes

 

I am primarily an advocate of cut-through because it gives better delay performance and the size of the insertion buffer can be smaller. However, many prefer store-and-forward. I think both modes should be allowed beause they interwork easily. No additional specification like a flag in the packet-header is required.

 

I am an advocate of three or even four traffic classes. But others like to work with two or even one class. It also depends very much on the appilcation area of the RPR. For every class one needs a receive buffer, an insertion buffer, a transmit buffer, the control and data paths, etc. Thus, more classes means considerable more hardware. Thus, more costs. With mapping one can optimize individual designs and preferences. Performance will be different but the nodes interwork. Mapping rules are easy.

 

I am an advocate of a scheduling mechanism that, for each class, first selects the insertion buffer and then the transmit buffer. Some will like to do that in an otherway. Again performance will be different but the nodes interwork.

 

In this way, each equipment manufacturer can decide on their product portofolio and the market can decide between performance and costs.

I think we define even a better MAC when some freedom is given without loosing interoperability.

 

Best regards, Harmen

 

----- Original Message -----

 

Re: [RPRWG] Cut through definition?

 

     To: stds-802-17@xxxxxxxx
     Subject: Re: [RPRWG] Cut through definition?
     From: "William Dai" <wdai@xxxxxxxxxxxx>
     Date: Wed, 18 Apr 2001 11:29:16 -0700
     References: <000e01c0c7e0$c67df880$6d588380@xxxxxxxxxxxxxxxx">000e01c0c7e0$c67df880$6d588380@xxxxxxxxxxxxxxxx>
     Sender: owner-stds-802-17@xxxxxxxx

 

 Dear Harmen,
 
 I really cannot agree with your "freedom" speech in the context of MAC definition.
 Let's not forget we're defining a "shared media" MAC.
 
 If my understanding is correct, you don't even want to standardize on the different
 class behavior of the MAC, right ? If you don't agree that there should be any class
 behavior class difference at MAC layer, I rest my case; otherwise, if you allow
 different node has different interpretation of the class behavior, then where is the
 "Interoperablity" coming from ?
 
 Best Regards
 
 William Dai
 
 

 

----- Original Message -----
From: Harmen van As
To: Ray Zeisz
Cc: stds-802-17@xxxxxxxx ; Wolfram Lemppenau
Sent: Wednesday, April 18, 2001 1:22 AM
Subject: RE: [RPRWG] Cut through definition?

 

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
        

------------------------------------------------------------------
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
------------------------------------------------------------------