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, 20022: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 astatic 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 negativelyaffected 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
multipleusecs.
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
hasto dothe
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, 20027: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: DolorsSala
[mailto:dolors@xxxxxxxxxxxx]
Sent: Wednesday,
February 06, 20022: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
thinkyou 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 OnnHaran
wrote:
>
> >The following presentation summarizes report message suggestion.
>
> >
>
> >Onn.