|
William:
Let
recapture the algorithm you have described:
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
and "Transit" M or L traffic
3. Preempted segment is not
allowed to be preempted again.
4. Preempted "Transmit" traffic will be
scheduled to transfer right after "Transit" H traffic,
regardless 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 insertion point.
6. Jumbo
frame is not supported for H class.
7. M and L
traffic should be store and forward (packet-wise) only on the ring
(to reduce the
complexity of reassembly job at the final receiver)
observations:
- I
think your answer to Zenon is once preempted, it can only be pre-empted at the
next escape point.
- While
the current scheme allows transit high to jump ahead of the low/medium
transmit packet, what about the high priority transmit packet that sits
behind the current preempted M/L packet. It suffers delay and jitter. Where do
we want to draw the line that consider a packet is in
flight?
- What about allowing the transmit
high priority packet to preempt transit M or L. Then it affects the high
priority transit delay and jitter.
- You
will need to add in the algorithm: the arbitration between transit high and
transmit high. Transit should have priority.
- insert of IDLE/ESCAPE are flags, that allows
predictable insertion points which is advantageous for scaling to high
rate.
- The
preempted packet size is now its original size plus the inserted packet whose
size is variable.For simplicity, cells should be created so the
processing of a packet in a packet can scale. This is a slotted ring. It is
not PHY agnostics.
- now
the MAC has to buffer at line rate for how many packets, if there are many
transmit high packets? What about in case of congestion?
- At
10G the 8K jumbo frame transmission time is 6.4 us.
- SLA
are starting to address the delay issues: Can you quantify the delay and
jitter for M and L?
I
believe the dot3 group call the jumbo frame issue "Vietnam". Rightfully so.
I'll ask the question, is jumbo frame even a god idea?
Regards,
Harry
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>
|