Additional comments on preemption,
cut-through and store-and-forward.
Cut-through means the packet on the ring
keeps moving unless the insertion buffer filling increases because the
node clocks a packet out of the transmit buffer. Moving means here, one
internal word unit is written into the insertion buffer and at the same time
one word unit is read out. Upon the arrival of empty words,
the filling of the insertion buffer deceases until zero. In front of the
insertion buffer stage, a pipe-lined header recognition stage also permits the
packet to move through. Thus, all header information is available at the end
of the header-recognition pipeline. In case that the packet is addressed to
the node, it is clocked to the receive buffer, otherwise to the insertion
buffer part. Scheduling between insertion and transmit
buffers is done at the transmit-side. The complexity
of the implementations for cut-through and store-and-forward are similar, with
cut-through being slightly more complex.
Since some companies prefer to use
store-and-forward and other ones cut-through, we propose to allow
both types because they easily interwork. The difference is in end-to-end
delay performance and the required.size of the transit or insertion buffer,
respectively.
Packet preemption is not yet an established
technik. Therefore, the immediate reaction of my exploder mail was that
is too complex! Or, why not use ATM in the first place? And my answer to one
of the comments is: Of course, I am talking about preemption during
transmission, nobody missed something. It is not complex and error handling
has been included!.
Without packet preemption by IP-telephony or
IP-conferencing packets, an all-IP world never will be able to
achieve the voice conversation quality that circuit-switching and
ATM can provide. A natural voice communication requires a maximal
end-to-end delay of 80-100 ms. Not more! Above that it becomes
more and more cumbersome. For free or low cost private calls, higher delays
might be acceptable. But not in the business world. For conversations over
larger distances, the propagation delay takes already a big part of the
permitted total delay (10.000 km gives 50 ms). Packetization for a payload of
only 40 bytes of 64 kbit/s voice gives an additional delay of
10 ms. This means for this distance 20-40 ms ist left for delays in the
network, including the playout buffer for delay jitter. Delays in the
endsystems have not been taken into account and for larger communication
distances, the remaining margin becomes proportionally smaller.
IP-telephony or IP-conferencing is not yet a commodity. The circuit-switched
networks and ATM networks still do their excellent job for voice, and they
carry the bulk of that service. Currently, network operators still not have to
worry much about the end-to-end delay issue. Everything is rather new,
current customers except the inferior quality, billing is not really
established, calls are currently much cheaper or free, so who cares at the
moment. IP-telephony or IP-conferencing is so sexy and hyp that
already that might justify it usage, even when it not works so fine all
the time.
The ATM cell size has been
chosen so small because of voice conversations. It is not at all
adequate for massive data communications. Natural communication between humans
is low volume compared with data, but it is certainly the most important
form for global human interactivity. Handling interactive voice in
packetized networks adequately is the most difficult and most
sentive form of communications. Why, one should return to walky-talky
communications with commands like 'over' as we want to move towards all-IP
networks. Also MPLS will not solve this issue.
Since there is futher an increasing pressure to
use very large data-packets in order that users can exploit the TCP-protocol
with much larger throughputs as today, packet preemption will be become
unavoidable. It is just a matter of time. In fact, packet preemption is
already been applied inside of some routers. I am sure preemption will also be
seen on lower speed router links soon. The first company with such a feature
on the market will immediately outperform all other routers in that respect.
IETF standardization will certainly follow that up. It has to be said that the
larger the distances and the higher the link speeds, the poorer works the
window mechanism of TCP with respect to throughput. Therefore, larger packet
will be required to keep the data explosion going.
Considering the max. size of a IP-packet of 64 Kbytes,
one obtains without preemption a jitter of SONET/SDH
155 Mbit/s - 3.495 ms per
node
622 Mbit/s - 0, 873 ms
2.5 Gbit/s - 0,218 ms
10 Gbit/s - 0,054
ms
For SONET/SDH 155 Mbit/s, the per node jitter delay
is
1 Kbytes - 0.054 ms per
node
5 Kbytes - 0.273 ms
10 Kbytes - 0,835 ms
20 Kbytes - 1,092 ms
40 Kbytes - 2,184 ms
60 Kbytes - 3,277 ms
Multiplied with the number of passing ring nodes,
these figures determine in fact the playout buffer, and that only caused
by the RPR. Not included are the additional delays in other network
nodes of the connection.
For high-bit rates rings, the figures are perhaps not so
impressive. However, for lower bit rate rings for manufactury plants, public
access, campus, or in-building areas, providing a huge market, it really
counts up. The more areas where the RPR can be used, the more
successful will be the IEEE 802.17 standard.
Since the preemptive mechanism raised some
questions, here some details.
- Three ring classes are considered
Class 1: Premium class (circuit emulation):
guaranteed throughput, tight delay jitter
Class 2: High- priority packet switching: guaranteed
throughput, bounded delay jitter
Class 3: Low- priority packet switching: best-
effort
- Class 1 may preempt classes 2 and 3
- Class 2 may preempt classe 3
- Class 1 uses cut-through
- Classes 2 and 3 must be store-and-forward to keep it
simple
- The preemption mechanism holds both for packets clocked
out of the insertion buffer and those leaving the transmit
buffer
- At the ring receive side, all packet embeddings are
resolved by forwarding the packets of the different priority classes into
their corresponding receive or insertion buffers
- Resolving means that within the considered received
packet, a new packet start of a higher class may appear
indicating an embedded packet lasting until its end of packet
shows up. This might happen more than once in a packet.
- Packets of the highest class are immediately
forwarded, thereby possibly preempting a packet of a lower class, either from
the insertion or the transmit buffer
- Due to store-and-forward operation of the insertion
buffers for the two lower classes all holes left back by the
embedded packets schrink together before they are forwarded onto the next
transmission hop.
By this operation it is assured that the time-sensitive
packets for IP-telephony and IP-conferencing pracktically shoot through the
network with minimal delay. Note that the ring might only be a small part of
the global connection and as previously explained all delay saving may count
to achieve the required end-to-end delay bound of 80-100 ms.
A mail on implementation complexity will follow.
It can also already be said that getting the start/end of
packets occurs in the same way as with an operation without preemption.
The MAC is thus agnostic.
best regards
Harmen