All,
I just want to clear
things concerning to Burst mode transceivers.
1. FSAN compliant 1.25Gbps D/S
and U/S transceiver with 3 or 12 bytes
(several nsec) overhead cost the same as
transceiver with (10 usec? overhead or 1 usec). This is because Laser Driver ASIC that can handle
short turn on delay cost the same as continues Laser Driver (LD), where
probably the same LD that support continues mode will support burst mode
with several nsec turn on delay.
2. FSAN compliant
transceiver cost the same as 802.3ah transceiver. The transceiver costs lies
on the optic (BIDI, Laser Diode, PIN ), and
definitely not on the Laser Driver ASIC, where 802.3ah transceiver uses the
same optical components (two or three port bidi)as
FSAN transceiver.
3. 8 bytes overhead, which
represents turn on delay of several nsecs provides almost 150Mbps bandwidth more over
the link than 1usec turn on delay. Turn on /off of 1usec is 156byets times
64 for TDM voice per ONU resulting in 10000 bytes + 64* 156 for DBA + 70
( for 1500buts per slot)*156 = 31000 bytes. 31000
bytes in 1 msec is around 200Mbps. 8 OH bytes only eat 64Mbps.
The price for end to end 8 bytes
OH cost the same as 156 bytes OH.
Regards
David
-----Original Message-----
From:
owner-stds-802-3-efm-p2mp@majordomo.ieee.org
[mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org]On Behalf Of
vincent.bemmel@xxxxxxxxxxxx
Sent:
Friday, February 08,
2002 2:20 AM
To:
stds-802-3-efm-p2mp@ieee.org
Subject: RE:
[EFM-P2MP] MPCP: Report message
All,
I'd like to follow
up on some of the discussions re: scheduling and REPORTs.
So far we have
identified two approaches to assigning timeslots:
1.
Static timeslot assignments -- no REPORTs
are generated by ONUs for BW
management.
-
The OLT sets up a static
timeslot scheduling plan, and generates GATEs
for each ONU
Two
options:
-
Each ONU receives a grant for a fixed timeslot at a time,
or
-
Each ONU recieves a grant for multiple
fixed timeslots for a period of
time (multi-cycle grant)
A TDM scheme is best
implemented through this approach. For
jitter/delay
sensitive TDM traffic, some of
us strongly believe multi-cycle granting is
the best way to go.
2.
Dynamic timeslot assignments -- REPORTs may be used to provide the
DBA
feedback loop.
-
The OLT now dynamically schedules timeslots, and generates GATEs for each
ONU accordingly.
-
Each ONU receives a grant for a fixed timeslot at a time. It may
optionally communicate it's BW
needs to the OLT via REPORTs.
Notice that DBA
designs are proprietary, and may desire a wide range of
parameters in the feedback
loop. Fortunately this is
(and should remain)
out of our scope. However, even in its simplest form,
the upstream BW
efficiency is negatively affected in order to support REPORTs upstream.
Here is an example
(assuming 64-Byte REPORTs).
In
order to have ONUs responsive with a granularity
of 1ms, the
overhead for a 64-split is
64x64B/(0.001s) = 32.8 Mbps + timeslot framing
overhead. As Bob pointed out, the latter
can easily be in the order of
multiple usecs.
E.g.,
3 usec = 600% overhead on a 64Byte (0.512 usec) frame.
So
*very* conservatively we can easily eat up > 20% of the
upstream
BW
just to make DBA work.
(That
would be > 60% BW overhead if the framing overhead was 10
usec).
Note:
numbers may look slightly better (statistically) with upstream
piggybacking of REPORTs in the case of higher upstream traffic
loads.
The tendency will be
to reduce these numbers by putting tighter constraints
on the lasers and clock
recovery mechanisms a la FSAN.
This equates to more
expensive components.
Now consider a
solution, based on DBA, that includes TDM
services... The ONU
now has to do the following:
-
wait for a GATE poll
-
send a REPORT (requesting TDM BW)
-
wait for a GATE (w/details of Timeslot to transmit TDM
data)
-
wait for actual time to send its data...
...
and repeat this for EVERY
TIMESLOT.
The actual overhead
needed to manage this mechanism is significant to say
the least.
Fortunately, today
we are faced with a 'glut' of bandwidth and the
need/requirement for dynamic
bandwidth provisioning is unnecessary.
Furthermore,
burdening the upstream bandwidth with a constant request
for
bandwidth is not warranted.
We have the
opportunity to introduce a more cost effective approach. That
translates to a solution that
will win acceptance in the marketplace, and
that is good for all of us.
Static mapping of
upstream bandwidth is sufficient, and TDM traffic can be
transported expediently. It means a less complex OLT and
ONU.
The nature of the
optics will limit the number of ONUs to 64. Once again,
this isn't a 2000-modem DOCSIS
system, nor does it exhibit the
dynamics of
a cellular phone system, so the
standard Aloha-based algorithms are not
required. This is not to say that they
should be dismissed,
but it is
important that multiple methods
of bandwidth scheduling should be allowed in
the protocol.
Vincent
-----Original Message-----
From: Horne, David M
[mailto:david.m.horne@xxxxxxxxx]
Sent:
Wednesday, February
06, 2002 7:55 PM
To:
'vincent.bemmel@xxxxxxxxxxxx'; dolors@xxxxxxxxxxxx;
ariel.maislos@xxxxxxxxxxx
Cc:
yoshi@xxxxxxxxxxxxxx; onn.haran@xxxxxxxxxxx;
stds-802-3-efm-p2mp@ieee.org
Subject: RE:
[EFM-P2MP] MPCP: Report message
re: Especially if the intention
is to have the OLT be responsive to ONU
requests
in near real-time,...
Can you define "near
real time?" Could be 6000-7000 timestamps elapse just
from transit delay. How would
we put a bound on processing and scheduling
delay at OLT if we are not
specifying scheduling algorithm?
There are many ways
to address the provision of upstream bandwidth requests,
but no one wants any level of
complexity or contention slots. That pretty
much means waste is a given.
This isn't necessarily a bad thing if it saves
complexity and doesn't encroach
on needed bandwidth. Have to show
quantitatively that the waste
is too excessive. It will be hard to do that,
given that unused reservations
don't follow any regular pattern.
--Dave
-----Original Message-----
From: Dolors Sala
[mailto:dolors@xxxxxxxxxxxx]
Sent:
Wednesday, February
06, 2002 2:48 PM
To:
ariel.maislos@xxxxxxxxxxx
Cc: Osamu Yoshihara;
onn.haran@xxxxxxxxxxx; Stds-802-3-Efm-P2mp
Subject: Re:
[EFM-P2MP] MPCP: Report message
Ariel,
We have several
requests on the table. Vincent is really interested in
supporting well TDM-like
services. Osamu is concerned on TCP data
transmission.
My argument is that
if you have to support both in the same system
(triple-play
is a requirement by some
service providers) the MAC client will be using
more
than one priority queue. In
this case, Osamu's dual request parameter is not
enough.
If we assume that
more than one priority queue is used, trying to avoid
fragmentation in a grant only
makes sense if the actual frames that
generated
the request are the ones
transmitted in the corresponding grant. Otherwise,
there is a size mismatch. And
the indication of a max and min size does not
help
on it.
I am not sure we
want to go to the detail of trying to avoid this
fragmentation.
But if we want to
enable this capability, I think we should specify a
general
approach. It is equally painful
to send an additional parameter upstream
than
downstream.
Note that sending
several consecutive requests would allow to
indicate frame
boundaries to the OLT without
additional parameters. If we are concerned on
a
single queue case, then we do
not need the parameter.
In summary, when the
discussion relates to the scheduling algorithm there
are a
lot of things that can be done.
Passing the appropriate information helps
tuning
particular implementations to
one or other application. The only information
missing on the system is the
priority in the grant. We have discussed this
and
we had not decided about it
yet. We should probably make the decision
together
with this request. I think this
parameter is a more general solution for
Osamu's
request. But I may be
interpreting wrong what he is suggesting. Osamu,
please
comment.
We can discuss more
during the call,
Dolors
Ariel Maislos wrote:
>
Dolors,
>
>
I do not think the concept of per-priority granting is appropriate.
It
looks
>
too much like DOCSIS service-flows to me.
>
>
What you are suggesting makes priorities meaningless. By
definition,
>
granting priority 4 while there is a pending packet of priority 1, (1
is
>
higher than 4) will transmit the packet having priority 1.
Behaving
>
otherwise makes priorities meaningless.
>
Operating otherwise looks like DOCSIS service-flows, and not like
802.1p.
>
>
The original presentation by Yoshihara-san tried to minimize
fragmentation
>
by granting exactly up to a FRAME BOUNDARY. This was suggested in
the
>
context of a flat FIFO queue.
>
I would suggest the appropriate way to do this is by using an
additional
>
field in the report (optional of course) that will give the number
of
bytes
>
at a frame boundary waiting in the queue. This number will be lower
than a
>
set threshold, while the threshold can be set statically or
dynamically.
>
>
Ariel
>
>
-----Original Message-----
>
From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
>
[mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org] On Behalf Of
Dolors
>
Sala
>
Sent: Sunday, February 03, 2002 5:53 PM
>
To: Osamu Yoshihara
>
Cc: onn.haran@xxxxxxxxxxx; Stds-802-3-Efm-P2mp
>
Subject: Re: [EFM-P2MP] MPCP: Report message
>
>
Osamu,
>
>
I think you are bringing
up a good point here. I think we can
>
consolidate
>
the two request types by modifying the interpretation of the
request
>
size.
>
>
If I interpret you correctly, you are looking for a requesting
mechanism
>
that exactly matches with the frames to be sent (and avoid left
over
>
space in the grant). Since the ONU is the one sending the request
and
>
knowing about the size of the packets in the queue, it is the one
that
>
can compute exactly how much bandwidth is needed to send a certain
set
>
of packets. Therefore I think we can achieve what you want by
saying
>
that
>
"the request indicates the amount of bandwidth (bytes) needed for
a
>
given priority". The ONU can compute the number by calculating
the
>
amount of bytes needed by adding for each packet all the
>
bandwidth components (the size of the packet, plus the interframe gap,
>
plus the phy overhead). This way, the
request exactly corresponds to
>
the grant size needed to transmit the packets the ONU had
selected
>
to request for bandwidth.
>
>
The buffer threshold in your presentation could be an ONU
policy
>
parameter. The ONU will decide how many packets to consider in
a
>
particular request based on a policy and a (potential)
maximum
>
request size (due to limit of the field size).
>
>
I think to achieve what you want, you also need the OLT to specify
the
>
priority of the grant. And this information should be sent up to the
MAC
>
client at the ONU when the grant arrives. Right now we had
provision
>
passing grant information from the MAC-control to the MAC client
and
>
this would be an example.
>
>
Would this do it?
>
>
Dolors
>
>
Osamu Yoshihara wrote:
>
>
> Onn,
>
>
>
> Thank you for the summary.
>
> I have one suggestion about REPORT content.
>
>
>
> I'd like to allow ONU to send 2 or more REQUESTs(number of bytes
>
> requested for queue) per priority queue in a REPORT
frame.
>
> For example, "minimum number of bytes requested for queue #n"
and
>
> "maximum number of bytes requested for queue #n".
>
>
>
> I made a presentation about this suggestion in
Austin.
>
>
>
(http://grouper.ieee.org/groups/802/3/efm/public/nov01/yoshihara_1_1101.pdf)
>
>
>
> We as NTT intend to use EPON system for TCP/IP data traffic
mainly.
>
> To yield high TCP throughput, low upstream delay is necessary,
and
>
> to keep upstream delay low, short grant cycle should be
required.
>
> When only "size of total buffered frames" is conveyed per
priority
queue,
>
> OLT can't always allocate exact requested bytes. It's because
granted
>
bandwidth
>
> per ONU becomes smaller when many ONUs
transmit REQUESTs.
>
> In this case bandwidth can't be allocated efficiently because
bandwidth
>
> wastage per ONU (maximum wastage per ONU is maximum MAC frame
size)
isn't
>
> negligible when grant cycle is short.
>
> To address this issue, we suggested to convey "frame
boundary
information"
>
> for high priority traffic in addition to "size of total
buffered
frames".
>
>
>
> OLT receives two types of request information, and chooses
appropriate
one
>
> as the granted bandwidth by a proprietary DBA algorithm. For
example,
when
>
> many ONUs transmit REQUESTs, "minimum number of bytes requested
>
> for queue" is chosen as "frame boundary information". In this
case
>
> there are no bandwidth wastage except guardband because the next ONU can
>
> transmit data frames just after the previous ONU finishes
transmitting.
>
>
>
> To send multiple REQUESTs ,"size of
total buffered frames" and
>
> "frame boundary information" ,is quite useful to yield high
TCP
throughput
>
> ,low upstream delay and high bandwidth efficiency for high
priority
>
traffic.
>
> And it is also useful for TDM traffic because low delay can be
achieved.
>
> (page 17 of
>
http://grouper.ieee.org/groups/802/3/efm/public/sep01/yoshihara_1_0901.pdf)
>
>
>
> Osamu Yoshihara
>
> NTT
>
>
>
> 2002.01.31 Onn Haran wrote:
>
> >The following presentation summarizes report message
suggestion.
>
> >
>
> >Onn.