RE: [RPRWG] Cut through definition?
DVJ
My personal view is that preempting lower traffic in the middle of a packet
adds complexity that is not really needed. At 1G, the transmission time for
a 1500 bytes packet is 12 usec, so the worst case for a 256 ring will be 3.1
msec of added delay because of low packets being transmitted and not
preeempted. Furthermore, the probability of the worst case is very small. We
did some simulations with the following assumptions:
- There is always a low priority packet being transmitted by the node
- High priority packet may arrive at any time during the low priority packet
transmission (equal probability)
Some of the results were presented during the January interim (by Gal Mor).
For a 128 nodes ring operating at 1G the preeemption gain will still be in
the msec range with very high probability, and this can easily be absorbed
by the jitter buffers at the receiver.
Leon
-----Original Message-----
From: David V. James [mailto:davidvja@xxxxxxxxxxx]
Sent: Friday, April 06, 2001 4:27 AM
To: Carey Kloss; Devendra Tripathi
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] Cut through definition?
All,
Relative to the discussion of cut through, et. al.
My perception is that a cutthrough node has two
insertion buffers, for classA (provisioned synchronous)
and classB (provisioned asynchronous).
The preferred transmit order is as follows:
a) classA insertion buffer (always)
b) classA transmit traffic (subject to provisioned rate)
c) asynchronous traffic.
The classA insertion buffer only needs to be the size of
the maximum packets sent by this node, plus (perhaps) some
extra symbols to deal with hardware decoding latencies.
The classB insertion buffer is to deal with the accumulation
asynchronous packets that occurs when (worst case) full asynchronous
is coming in/out and rate-limited synchronous is being transmitted.
The size of the classB buffer is on the order of several upsteam-link
delays times rateOfSynchronous/rateOfLink ratio.
Order of the asynchronous traffic (c) depends on the classB
buffer-filled status, prenegotiated vs. consumed rates, and
the size of the asynchronous backlog in the client.
The asynchronous transmit buffer is a bit schitzophrenic on its
behavior. It should be in the client (not the MAC) because that
allows packets to be reordered/inserted/deleted until the just
before transmission time. However, the amount of traffic in the
asynchronous transmit queue may influence the MAC queue-selection
and throttle-signal assertion properties.
I personally favor allowing cut-through synchronous traffic to
preempt asynchronous, even in the middle of a packet. That's
yields the lowest possible jitter, but at some encoding complexity
costs.
DVJ