Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[RPRWG] preemption, cut-through and store-and-forward



My comments on preemption, cut-through and store-and-forward.
 
Wolfram Lemppenau and I came to the firm conclusion that IEEE 802.17 should not standardardize whether the ring nodes must be based on cut-through or store-and-forward neither it should standardize whether packet preemption or not is used. Also scheduling between the different insertion and transmit buffers and the number of ring classes should be defined with some degree of freedom. It should be the freedom of each company how to the design their ring nodes. I am convinced that in some environments it is avantageous to use rings with packet preemption and cut-through, while rings in an other environment operate very well with store-and-forward and non-preemptive priorities, at the other extreme. The only thing that the standard must assure is their operability, so that also rings with a mixture can operate.
 
To our opninion, this is not very difficult to achieve, neither from the hardware nor from the algorihmic point of view. Here, the following issues are however crucial.
 
First, the ring-receiver side of the nodes must be aware that incoming packets may have been preempted by a packet of a higher-priority. Thus, the RX-side must be able to extract embedded high-prority packets and put them in their appropriate buffers. Since it is not allowed to preempt packets within the same class, no reassembly buffers are required.
 
Second, the ring-receiver side of the nodes must be able to map packets with a given prioity onto the number of available receive or insertion buffers. For example, when some nodes have six ring classes and other nodes uses three classes, then by-passing packets of priorities 1 and 2 go for instance to insertion buffer 1, those with priorities 3 and 4 to insertion buffer 2, and the other two priorities to insertion buffer 3, whereby priority 1 is the highest priority. What must be defined is the maximum number of ring classes and how class mapping has to be done. Even interworking with a node having only one ring class, i.e. one receive and one insertion buffer, must be possible. In that case, the ring-receiver side only resolves possible packect embeddings only if both or more packets in the interleaved packets are addressed to the ring node itself, otherwise the interleaved packet is forwarded as a whole, i.e. as received from the ring.
 
Third, and this ist the most difficult part, the MAC itself coordinating the access to the ring in a fair manner must be standardized. Here, nodes should obtain rates for each of the ring classes (or credits) as periodically determined from fairness cycles of dynamic length.
 
Cut-through and preemption are most crucial when data packets are large, link bit rates are rather low (e.g.155 Mbit/s), IP-telephony becomes a commodity, and carrier-grade voice service have to be guaranteed in a simular fashion as in circuit-switching.
 
It has been argued that current date packets have a max. size of about 1500 bytes, so preemption for GbE-links does not bring much in performance. I do not consider it very wise to limit the applicability of a standard to current packet sizes. IP allows for instance roughly 64 Kbytes and one can be sure that jumbo-packets will come, sooner or later. At that moment, preemption for interactive realtime sessions becomes mandatory.
 
Second it has been argued in backbones the link speeds are so high, that their is no gain due to preemption or cut-through. I agree. However, should the standard not be applicable to many other areas such as manufatury plants, public access, campus, or in-building areas, providing a huge market? In these rings, we will find much lower rates (100 Mbit/s, 155 Mbit/s,...). The more areas RPR can be applied, the more successful becomes the standard. And all, with a company and operator freedom without much additional standardisation effort and only with not very much additional implementation effort at the ring-reciever side.
 
Third, it has been argued that ATM requires segmentation and reassembling making its implementation very difficult. Therefore, one should not use preemption for the RPR. What occurs in ATM is that cells belonging to packets from different sources may arrive at a receiver node in a completely interleaved and scattered way and therefore a number of assembly machines and the corresponding buffer spaces are required. Preemption on point-to-point links or on a ring means priority class preemption. The ring-receivers never obtains interleaved packets of the same class. Thus, receiving is not more difficult as receiving virtual tributaries in SONET or containers in SDH, consisting of interleaved overhead and payload parts.
 
Packet preemption is already applied inside of routers. It will not take long and preemption will also been seen on the router links. The receiver side of the next router must just be aware of that and it interworks with routers that do not apply preemption at their transmit side.
 
It should further be noted that the size of the ATM cell became so short because of voice connections. Massive voice-conections over ATM work excellent and they are able to exhibit circuit-switched end-to-end delays. In contrast, IP is still far away from that standard. It should be noted that the end-to-end delay of voice and multimedia-conferencing based on pure circuit-switching and cable transmission are at most 100 ms, even for distances to the other end of the globe. Multimedia-experts postulate that real-time human interactivity is only pleasent at a maximal end-to-end delay of 80 ms, at most 100 ms. Today Internet works with 200-300 ms, depending on the number of passed routers. Thus, far from the traget 80-100 ms.
 
The end-to-end delay in packetized voice and conferencing communications mainly consists of
- compression delay
- paketization delay
- network access dealy
- delays in all passing nodes
- propagation delay (5 us/km)
- depaketization delay
- decompression delay
- play-out buffer delay for the jitter
 
The distance determines the propagation delay. What is left from the target delay can be used for all other delay components. In some cases there will be no time to use compression/decompression. The bottom line for the RPR is that each millisecond less delay in the transmission path might be crucial for the end-to-end connection. The standard should not prevent companies to design products with packet class preemption.
 
Preemption, cut-through and store-and-forward should all be allowed in IEEE 802.17
 
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
------------------------------------------------------------------