| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 ------------------------------------------------------------------ |