Re: [RPRWG] Cut through definition?
As a mailing-list lurker, I am fascinated by these discussions on preemption.
First, a response to William Dai, especially with his third point:
-- 3. Preempted segment is not allows to be preempted again.
So if a low-priority "Transmit" packet just begins transmission, and a high-priority "Transit" packet arrives, the low-priority "Transmit" packet is preempted. (according to point #2).
OK, so the high-priority "Transit" packet is done, and the low-priority "Transmit" packet continues transmission. Now another high-priority "Transit" packet arrives. Oops... the current low-priority "Transmit" packet has already been preempted once, so the high-priority "Transit" packet has to wait.
So, with the added complexity of preemption, the first high-priority "Transmit" packet was "accelerated", but not the second -- and subsequent -- high-priority "Transmit" packets; these high-priority "Transmit" packets have to wait. Essentially, the problem remains.
--------
Folks have been saying that preemption is much more important on low-speed lines. The classic example given was a small real-time voice packet stuck behind a large non-real-time packet on a 56kbps pipe. [I thought one solution to this classic example is not preemption, but to have a smaller maximum-transmission-unit, thus reducing the maximum wait. The smaller MTU would possibly involve packet fragmentation, but not preemption.]
So maybe one way around this whole "do we or don't we preempt?" is to bound the problem. For example, "Preemption SHOULD be supported if the transmission time of the longest frame is greater than <some significant amount of time, likely on the order of milliseconds>." That way, folks who are looking to design multi-Gbps pipes can just skip the entire preemption discussion.
Just a thought as I watch my Sharks losing 1-0....
Zenon Kuc
At 12:16 PM 4/12/01 -0700, William Dai wrote:
>>>>
Although I'm not a big preemptive transfer fan, but I think this topic deserves detailed
discussion before we rush into any conclusion. What changes me is the discussion of
Jumbe Frame support on RPR, not long ago it was 2KB, now it is 9KB, what about the
ultimate 64KB in the future ?
By saying that, I'm proposing neither ATM cell like structure nor slotted ring structure,
and since RPR MAC is L1 agnostic, physical signalling trick cannot be used either.
Let me give one example of preemptive transfer definition here and let's discuss what
is so complicated (simple) about it.
1. There are 3 MAC classes of traffic (H, M, L,).
2. Preemption is allowed only for "Transit" H traffic to preempt "Transmit" M or L traffic.
3. Preempted segment is not allowed to be prempted again.
4. Preempted "Transmit" traffic will be scheduled to tranfer right after "Transit" H traffic,
independent of classes.
5. Each Packet transfer will be inserted an "IDLE/Escape" word for every 256 or 512
(for the sake of alignment/padding concern) byte as the preemptive inserion point.
6. Jumbo frame is not supported for H class.
By the way, SONET clock distribution is not needed. After all, RPR is a packet based network.
Best Regards
William Dai
----- Original Message -----
From: <mailto:hpeng@xxxxxxxxxxxxxxxxxx>Harry Peng
To: <mailto:nuzun@xxxxxxxxxxxxxxxx>Necdet Uzun
Cc: <mailto:Sushil.Pandhi@xxxxxxxxxxxxxxx>Sushil Pandhi ; <mailto:leonb@xxxxxxxxxxxxx>Leon Bruckman ; <mailto:'davidvja@xxxxxxxxxxx'>'davidvja@xxxxxxxxxxx' ; <mailto:stds-802-17@xxxxxxxx>stds-802-17@xxxxxxxx
Sent: Thursday, April 12, 2001 7:23 AM
Subject: RE: [RPRWG] Cut through definition?
Exactly my point.
"we should keep it simple and not Segment packets. " i.e. Do not preempt.
Regards,
Harry
-----Original Message-----
From: Necdet Uzun [mailto:nuzun@xxxxxxxxxxxxxxxx]
Sent: Wednesday, April 11, 2001 6:22 PM
To: Peng, Harry [SKY:1E11:EXCH]
Cc: Sushil Pandhi; Leon Bruckman; <mailto:'davidvja@xxxxxxxxxxx'>'davidvja@xxxxxxxxxxx'; <mailto:stds-802-17@xxxxxxxx>stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] Cut through definition?
I am not clear how the proposed preemption method works.
Does a high priority transit packet preempt a low priority add packet?
Can a high priority add packet also preempt a low priority transit packet?
What happens if a previously preempted add packet contends with a same priority packet that was also preempted in an upstream node?
What happens if a previously preempted add packet contents with a same priority previously preempted transit packet that follows a high priority preempting transit packet with a clock cycle gap in between due to clock mismatch?
Do we require a SONET clock to be distributed on the ring?
Is RPR MAC layer one agnostic?
Thanks.
Necdet
<snip>