|
Zenon,
Obviously, your interpretation of my #3 statement is not
really what I mean.
Let me fill the holes in my wording.
3. Preemptive insertion can only happen at
any IDLE/ESCAPE word of
M or L
packet.
Maybe the wording is still not perfect, but you
should get the point.
I would like to take this chance to enhance the definition
(credit to Harmen ven As)
2. Preemption is allowed only
for "Transit" H traffic to preempt
"Transmit" M or L traffic and "Transit" M or L traffic.
4. Preempted traffic will be
scheduled to tranfer right after
"Transit" H
traffic, regardless of classes.
7. M and L traffic should be store and
foward (packet-wise) only on the ring
(to reduce the complexity of reassembly job at the final receiver)
By the way, you're risking your "political future" in another
frontier by prefering
fragmentation :))
William Dai
----- Original Message -----
Sent: Thursday, April 12, 2001 6:12
PM
Subject: 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>
|