|
Harry,
First of all, I'm not a "Jumbo Frame" proponent. The reason
that turns me
into the "Preemption" minority camp is because I feel most
likely we will
lose the war against Jumbo Frame. Why ? just look how ATM
failed. ATM
is designed to be network (switch) friendly but is not end
station (legacy
host) friendly, while the market situation
is always to keep end station
simple. In those "QoS what QoS" days, the
results is obvious. Jumbo Frame
is the continuation of that market situation, but today, QoS
is becoming a
serious issue is the network (switch) design.
Let me comment on your observation
list.
#1 Yes
#2 Since the Transmit M/L
has already been scheduled to transfer, it
makes
no difference in terms of delay/jitter for Transmit H packet,
whether preemption occurs or not, since Transit H packet will be
scheduled ahead of Transmit H packet.
#3 I'm not proposing it,
since I only concern about the delay/jitter for H
on
the RPR ring. But it is not as "trouble maker" as you thought.
#4 Agree.
#5 Agree.
#6 Need further
study.
#7 If the buffer you
mentioned is Transmit Buffer, it should reside in
upper
layer. If you mean Transit Buffer, for H class it should be a
little bit more than max(H class MTU, segment size (e.g. 512byte)),
for M
and L class, the size is related with scheduling algorithm and
"fairness" algorithms.
#8 I trust your
calculation.
#9 TBD depends on
scheduling/"fairness" algorithms.
Regards,
William Dai
----- Original Message -----
Sent: Friday, April 13, 2001 9:40
AM
Subject: RE: [RPRWG] Cut through
definition?
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>
|